Hi, I review the version on github and have a few high level comments.
Cheers, John - Section 1 "The cleartext Server Name Indication (SNI) extension in ClientHello messages, which leaks the target domain for a given connection, is perhaps the most sensitive information unencrypted in TLS 1.3." External PSK identities are probably even more sensitive, but are of course not as commonly used as SNI. The draft should definitly mention external PSK identities. - Section 1 "and other potentially sensitive fields, such as the ALPN list." I think there is much more than SNI and ALPN that can be sensitive. I think the draft should mentioned that the set of extensions and their content as a whole can be used to identity a specific application (e.g. Tor, File sharing, dating apps, etc.). The list of supported cipher suites is well-known to have been used in practice for fingerprinting. Section 10.2 “In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource Records are signed via a server private key, ECH records have no authenticity or provenance information. This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply clients with fake ECH records (so that the client encrypts data to them) or strip the ECH record from the response. However, in the face of an attacker that controls DNS, no encryption scheme can work” I think the statement "no encryption scheme can work" is to strong. If the authenticity of ECHConfig is assured it mitigates attacks where an attacker inject false ECHConfig to lure the client to encrypt data to the attacker. Furthermore, the presence of ECHConfig could fool the client to do something they would not do otherwise, like using usign a sensitive application like Tor, File sharing, dating apps, etc. which could get the person in trouble. I think the draft needs to state that something like: “if the authenticity of ECHConfig cannot be assured, it is unknown who can decrypt the InnerClientHello. Client shall not change their behavior based on unauthenticated ECHConfig”. Section 10.2 ”Thus, allowing the ECH records in the clear does not make the situation significantly worse.” ”SNI encryption is less useful without encryption of DNS queries in transit” These two statements seems slightly contradicting. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
