Draft: draft-ietf-tls-esni

Commentary: This assumes the GREASE threat model is a misbehaving and lazy middlebox . That is , we aim to prevent ossification . It does nothing more to prevent an active attacker from learning whether or not a particular connection used GREASE . ( That problem is probably better suited to something like MASQUE . ) cc 
 Merging for now . We can come back later and address followup extensions if needed ! 
 The draft has provisions for GREASE ESNI extensions , per " Do not stick out " . However , this is not very effective if an attacker can distinguish a GREASE ESNI extension from a real one . tried to address this , but it does n't work if the ( public ) ESNI record is known . There 's also a simpler attack : replay the ClientHello with one byte of ciphertext corrupted . ESNI currently distinguishes key mismatch from decrypt failure , with the latter resulting in an alert . We can fix that by saying decrypt failure should behave like key mismatch . This still leaves recorddigest . The natural fix is to drop recorddigest in favor of trial decryption . The cost is the server must perform a DH operation per known key . The number of keys the server needs depends on its DNS TTLs and key rotation . ( I think it 's 1 + ceil(dnsttl / timebetweenrotation ) , plus some leeway [ ] . ) Instead , we can keep a key name , but make the space dense . Suppose we replace it with a B - bit " key phase " . The server picks a random starting key phase . Then , each time it rotates the keys , it increments the phase , with wraparound . The server then gets 2 < supB</supkeys for free . If it needs more , it still needs trial decryption but gains a 2 < supB</supmultiplicative factor in the cost . On the flip side , an individual GREASE extension with a random key phase has a 1/2 < supB</supchance of colliding with a particular ESNI key . I 'm not sure we actually need that many live keys , so B = 2 is probably plenty . Or even B = 1 if we say you should just rotate slower than your DNS TTL . [ ] Note the robustness mechanism means that server does n't need to cover all clients with stale keys . The retry is expensive , so the server still needs to cover almost all _ of them , but it can cut off the long tail . 
 Mostly a note to myself for the actual PR : the draft should also discuss padding of the EncryptedExtensions message . 
 I think we really need to go back to first principles here and ask what it is we are trying to accomplish . First , it 's public information whether a given server supports ECHO , so if an attacker wants to know that , it can mostly just ask [ there is some complexity around getting candidate names , but note that you can always get the public name from the SNI value and any real attacker will see a lot of non - ECHO traffic and so will know a bunch of SNI values ] . What 's not public information is whether a given connection uses ECHO . The attacker might not know this either because : knows that the server is ECHO - supporting . has a limited view of just the connection and is n't willing to do do the work of trying to determine if the server is ECHO - supporting . In case ( 1 ) I would also expect that the attacker is not going to go to the trouble of doing probe connections , as determining if the server is ECHO supporting is easier . This leaves us with the case where the attacker knows that the server is ECHO supporting and that the client knows about ECHO ( otherwise it could n't generate GREASE ) but does n't know if the client is actually doing ECHO . Do we expect there to be a lot of clients like this ? Why not just do ECHO ? 
 As per today 's call , we 're going to revisit the GREASE threat model and then reconvene if further work is needed . 
 I 'm moving to closes this issue as resolved by . If we need to do something against connection blocking adversaries , perhaps we should look into MASQUE for that . 
 Closing for now . please re - open if you still think we should address this !
Paragraph (version A):
Set the "encrypted_ch" field to a randomly-generated string of
[TODO] bytes.
Paragraph (version B):
Set the "encrypted_ch" field to a randomly-generated string of L
bytes, where L is the size of the ClientHelloInner message the
client would use given an ECHOConfig structure, padded according
to padding.