On Mon, Sep 30, 2024 at 3:12 PM Ben Schwartz <[email protected]> wrote:

> OK, done: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16
>

Looks good other than some minor suggestions I made.

Thanks for correctly pointing out that DNSSEC doesn't help you when you are
dealing with privacy and untrusted DNS servers.

As for the RFC1034 reference, Warren suggested to maybe use:  "DNS (see
RFC1034, BCP219)"  (where BCP219 is the latest DNS Terminology doc).

Paul

------------------------------
> *From:* Salz, Rich <[email protected]>
> *Sent:* Monday, September 30, 2024 1:29 PM
> *To:* Ben Schwartz <[email protected]>; Eric Rescorla <[email protected]>; Paul
> Wouters <[email protected]>
> *Cc:* [email protected] <
> [email protected]>; <[email protected]> <[email protected]>;
> [email protected] WG <[email protected]>
> *Subject:* Re: [TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech
>
> We could add a recommendation like "Clients using ECH SHOULD select a DNS
> resolver that they trust to preserve the confidentiality of their queries
> and return authentic answers, and communicate using an authenticated and
> confidential transport",
>
> We could add a recommendation like "Clients using ECH SHOULD select a DNS
> resolver that they trust to preserve the confidentiality of their queries
> and return authentic answers, and communicate using an authenticated and
> confidential transport", but this draft seems like an odd place for that
> text.
>
>
>
> When DNS SVCB has an ech entry, DNS is being used a little differently
> than your conventional DNS for ipaddress, since you can use TLS to
> authenticate what DNS told. For ECH you cannot.  In other words, I think
> recommendation, or warning in security considerations, is exactly right for
> this document.
>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to