Hi, I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well summarized by the Document Shepherd:
Please note that the text in this I-D was initially developed in the DNSOP WG, went through IETF LC, and IESG review. The result of the IESG review was to take the text in this I-D out of RFC 9460 <https://datatracker.ietf.org/doc/rfc9460/> (was draft-ietf-dnsop-svcb-http) and run the new I-D through the TLS WG. The text in this I-D is essentially the same text taken from -11 of draft-ietf-dnsop-svcb-http. This is why I sent this review to both the TLS and DNSOP list. I have a few minor issues in the draft that I think need fixing: These downgrade attacks can prevent a client from being aware that "ech" is configured which could result in the client sending the ClientHello in cleartext. However, when DNSSEC is used and the TLS client can see the errors at the DNS layer, it can detect this downgrade attack is happening, and decide whether or not to continue with starting a TLS connection. I think the text should explain the difference in attack scenario in the presence and absence of DNSSEC. It might even be worth it to RECOMMEND DNSSEC, or recommend a DoH / DoT / DoQ connection to a DNSSEC supported DNS service. When referring to "DNSSEC", please use a normative reference to RFC9364. I think referring to DNS as RFC1034 is a mistake. It would be much better to refer to RFC9499 See Section 7.2.2 <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20#section-7.2.2> of [ECH <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20>] for more details about the public name. This section does not exist (anymore?). I am not sure what it was trying to point to? The public_name text in Section 4 ? Note that the ECH document defines the public_name as not ending in a dot, which technically prevents the root from ever using SVCB ECH records. This is probably okay, but I'll raise it again as part of the ECH document AD review. Paul
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
