Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt

[Christian Huitema <[e-mail]>]

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.

-- Christian Huitema