Draft: draft-ietf-tls-esni

Commentary: The purpose of " echnonce " is to mitigate the " client reaction " attack described in security considerations . It is redundant , however , since the serves the same function . This change removes the " echnonce " extension and clarifies the client behavior so that securely generating is an explicit requirement . This addresses . Based on . 
 LGTM 
 There are several rationales provided about the need for : nonce ensures that the server 's encrypted Certificate can only be read by the entity which sent this ClientHello . servers process either  or ClientHelloOuter , and ClientHelloInner contains an HPKE - derived nonce , it is not possible for an attacker to " cut and paste " the ECH value in a different Client Hello and learn information from ClientHelloInner . This is because the attacker lacks access to the HPKE - derived nonce used to derive the handshake secrets . Reaction Attack Mitigation ... The " echnonce " extension in the inner ClientHello prevents this attack . In particular , since the attacker does not have access to this value , it can not produce the right transcript and handshake keys needed for encrypting the Certificate message . Thus , the client will fail to decrypt the Certificate and abort the connection . These rationales are all subtly different , and having read them all , I still do n't understand why the nonce is necessary , when the serverhandshaketrafficsecret already depends on the inner client random , which is not known to the attacker . I would appreciate some more explanation on this point . It also might make sense to move these rationales up into the echnonce section , or add forward references to them there . 
 I agree that the rationale is n't clear from the description . This needs to be cleaned up . However , it does seem to prevent a real attack ( see Sec . 10.8.1 ) . 
 As I noted above , the serverhandshaketraffic_secret already depends on the inner client random , which is not known to the attacker . It therefore seems to me that the attacker therefore can not produce a Certificate message that the client will decrypt , even without the nonce . If that 's true , I do n't see how the attack in Sec . 10.8.1 is possible . 
 What if the inner is the same as the outer This is currently allowed by the spec , i.e. , there 's no guidance on " copying " extensions from the outer CH to the inner . 
 That 's an interesting question that I think the spec should probably address . I assumed they could not be the same , because they are both required to be random . If they can be the same , I would suggest making them always the same , and remove the inner one to save 32 bytes and simplify the analysis . 
 The semantics of copying outer CH extensions into inner CH needs to be clarified : see also To my read , the intent is that any extension MAY be copied , bit - by - bit , into the inner CH . 
 The client random is a fixed field of the ClientHello , not an extension . 
  , I 'm not really a fan of this ( and bit shaving in general ) . The idea is to make the inner CH as close to a full CH as possible , so keeping the same encoding makes most sense to me . That said , even if they are random , there may be cases where the attacker can predict the randomness generated . 
 I think an attacker that can predict a random value generated by the TLS stack has much more exciting avenues of attack here . ( E.g. the client 's key share is lost . ) Though it is a good point that they are slightly different : the ECH nonce is exported from the HPKE context while the client random is simply random . I forget if that ends up being important anywhere . 
 Ah you 're right . Thanks ! 
 Exactly -- even if an attacker knew the client 's key share , random value , etc , it might not know the ECH nonce ( without access to the sever 's private key ) , depending on the KEM used . ( If  was used , it would know the client 's ephemeral private key , so the point is moot . ) All that said , we may be able to remove it . But I 'm hesitant to do so without backing analysis . 
 I think this is true for any KEM . If your KEM looks more like public key encryption , the attacker would instead know the shared secret the client generated . More generally , if we assume the client is incapable of generating random numbers , the attacker can simply run through the client 's implementation of SetupBaseS , replacing all non - determinism with the predicted random number . It will then end up with the same HPKE context . 
 That 's true ! 
 RFC 8446 Appendix C.1 says " Implementations can provide extra security against [ broken RNG ] attack by using separate CSPRNGs to generate public and private values . " . If that 's the motivation for the nonce , I think the spec should mention it . 
 For what it 's worth , the checks out after removing " echnonce . " 
 This is the current proposal for removing " ech_nonce " and clarifying behavior around choosing the 
 Closing now that landed .
Paragraph (version A):
A 16-byte nonce exported from the HPKE encryption context, as
described in send-ech.
Paragraph (version A):
In order to send an encrypted ClientHello, the client first
determines if it supports the server's chosen KEM, as identified by
"ECHConfig.kem_id".  If one is supported, the client MUST select an
appropriate "HpkeCipherSuite" from the list of suites offered by the
server.  If the client does not support the corresponding KEM or is
unable to select a suitable "HpkeCipherSuite", it SHOULD ignore that
"ECHConfig" value and MAY attempt to use another value provided by
the server.  The client MUST NOT send ECH using HPKE algorithms not
advertised by the server.
Paragraph (version A):
Note that the HPKE functions Deserialize and SetupBaseS are those
which match "ECHConfig.kem_id" and the client's chosen preference
from "ECHConfig.cipher_suites".
Paragraph (version A):
TLS padding RFC7685 (see padding).
Paragraph (version A):
When offering an encrypted ClientHello, the client MUST NOT offer to
resume any non-ECH PSKs.  It additionally MUST NOT offer to resume
any sessions for TLS 1.2 or below.
Paragraph (version A):
Finally, the client MUST generate a ClientHelloOuter message
containing the "encrypted_client_hello" extension with the values as
indicated above.  In particular,
Paragraph (version A):
encrypted_ch contains the AEAD-encrypted ClientHelloInner.
Paragraph (version A):
The client MUST place the value of "ECHConfig.public_name" in the
ClientHelloOuter "server_name" extension.  See outer-clienthello for
additional discussion of ClientHelloOuter values.
Paragraph (version B):
To offer ECH, the client first chooses a suitable ECH configuration.
To determine if a given "ECHConfig" is suitable, it checks that it
supports the KEM algorithm identified by "ECHConfig.kem_id" and at
least one KDF/AEAD algorithm identified by "ECHConfig.cipher_suites".
Once a suitable configuration is found, the client selects the cipher
suite it will use for encryption.  It MUST NOT choose a cipher suite
not advertised by the configuration.
Paragraph (version B):
It MUST offer to negotiate TLS 1.3 or above.
Paragraph (version B):
It MUST include an "encrypted_client_hello" extension with a
payload constructed as described below.
Paragraph (version B):
The value of "ECHConfig.public_name" MUST be placed in the
"server_name" extension.
Paragraph (version B):
It MUST NOT offer to negotiate TLS 1.2 or below.
Paragraph (version B):
It MUST NOT offer to resume any non-ECH PSK or any session for TLS
1.2 and below.
Paragraph (version B):
It MAY offer any other extension in the ClientHelloOuter except
those that have been incorporated into the ClientHelloInner as
described in outer-extensions.
Paragraph (version B):
It SHOULD contain TLS padding RFC7685 as described in padding.
Paragraph (version B):
"encrypted_ch", as computed above.
Paragraph (version A):
If decryption fails, the server MUST abort the connection with a
"decrypt_error" alert.  Moreover, if there is no "ech_nonce"
extension, or if its value does not match the derived ech_nonce, the
server MUST abort the connection with a "decrypt_error" alert.  Next,
the server MUST scan ClientHelloInner for any "outer_extension"
extensions and substitute their values with the values in
ClientHelloOuter.  It MUST first verify that the hash found in the
extension matches the hash of the extension to be interpolated in and
if it does not, abort the connections with a "decrypt_error" alert.
Paragraph (version B):
If decryption fails, the server MUST abort the connection with a
"decrypt_error" alert.  Next, the server MUST scan ClientHelloInner
for any "outer_extension" extensions and substitute their values with
the values in ClientHelloOuter.  It MUST first verify that the hash
found in the extension matches the hash of the extension to be
interpolated in and if it does not, abort the connections with a
"decrypt_error" alert.
Paragraph (version A):
Since servers process either ClientHelloInner or ClientHelloOuter,
and ClientHelloInner contains an HPKE-derived nonce, it is not
possible for an attacker to "cut and paste" the ECH value in a
different Client Hello and learn information from ClientHelloInner.
This is because the attacker lacks access to the HPKE-derived nonce
used to derive the handshake secrets.
Paragraph (version B):
Since servers process either ClientHelloInner or ClientHelloOuter,
and because ClientHelloInner.random is encrypted, it is not possible
for an attacker to "cut and paste" the ECH value in a different
Client Hello and learn information from ClientHelloInner.
Paragraph (version A):
The "ech_nonce" extension in the inner ClientHello prevents this
attack.  In particular, since the attacker does not have access to
this value, it cannot produce the right transcript and handshake keys
needed for encrypting the Certificate message.  Thus, the client will
fail to decrypt the Certificate and abort the connection.
Paragraph (version B):
ClientHelloInner.random prevents this attack.  In particular, since
the attacker does not have access to this value, it cannot produce
the right transcript and handshake keys needed for encrypting the
Certificate message.  Thus, the client will fail to decrypt the
Certificate and abort the connection.
Paragraph (version A):
ech_nonce(0xff03), with the "TLS 1.3" column values being set to
"CH", and "Recommended" column being set to "Yes".