On Tue, Jun 2, 2020, at 10:28 AM, Christian Huitema wrote: > > > On 6/2/2020 5:44 AM, Christopher Wood wrote: > > On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote: > >> This draft looks really good. I just have two questions of clarification. > > I am not sure that I understand the point made in appendix B, Total > Client Hello Encryption. The text in that appendix explains that "The > design described here only provides encryption for the SNI, but not for > other extensions, such as ALPN." This seems to contradict the design > description in the introduction, "The design in this document > introduces a new extension, called Encrypted Client Hello (ECH), which > allows clients to encrypt the entirety of their ClientHello to a > supporting server." Am I correct to assume that the text in appendix B > is a leftover from the previous version of the draft? > > Yep! I'd opt to remove this text entirely, but if others want to keep it I > > suppose we can update the text accordingly. That's probably the simple > > option, yes. > >> I am also not sure on how we could implement the "Optional Record > Digests and Trial Decryption" methods described in section 10.3. The > syntax description in section 5 specifies the record digest as "opaque > record_digest<0..2^16-1>", and defines that field as containing "A > cryptographic hash of the ECHConfig structure from which the ECH key > was obtained". Would it be correct to implement the "optional record > digest" method by just encoding a zero length field? > > Indeed, that was the intent. Would you prefer a different way? > Length 0 is a fine way to mark the absence of an optional component. > But I would like a short mention of that either in section 5 or in > section 10.3. For example: > > > > 10.3. Optional Record Digests and Trial Decryption > > Optional record digests may be useful in scenarios where clients and > client-facing servers do not want to reveal information about the > client-facing server in the "encrypted_client_hello" extension. In > such settings, > > >> clients prevent server identification by sending > >> an empty record_digest field in the ClientEncryptedCH, and > > servers must perform trial decrypt upon receipt of an > empty record digest, which may exacerbate DoS attacks. Specifically, > an adversary may send malicious ClientHello messages, i.e., those > which will not decrypt with any known ECH key, in order to force > wasteful decryption. Servers that support this feature should, for > example, implement some form of rate limiting mechanism to limit the > damage caused by such attacks. > Fairly minimal change, but it would clarify the intent and avoid > interop problems.
Would you mind creating a PR for this? :-) Thanks, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
