Draft: draft-ietf-tls-esni

Commentary: This PR aims to resolve the discussion in issue by : goals / non - goals for " do n't stick out " ; and a TODO for a future experiment that assesses the deployability of the GREASE extension . Dealing with PSK sticking out has been assigned to . 
 Rebased on top of ECH-10 changes -- addressing comments next . 
 this is ready for your second pass . I took your suggestion of substantially reducing the amount of text . It should be a bit more concise and to the point , if less precise . I did n't mean to frame GREASE this way . Can you be more specific about how the text frames it this way ? 
 As discussed in , there are two real - ECH / grease - ECH differentiators related to the PSK extension we may wish to address . ECH disallows the PSK extension in ClientHelloOuter , whereas grease ECH permits PSK in ClientHello . ECH allows PSK in ClientHelloInner . In case of acceptance , the backend server may respond with PSK in ServerHello . The response would appear to be unsolicited . something that would not happen in a grease - ECH or vanilla handshake . The question we will ask ourselves here is if / how to mitigate these differentiators . We might simply say that clients MAY ( or SHOULD ? ) send a dummy PSK in the ClientHello(Outer ) . This ought to provide sufficient cover . 
 I do n't mind a MAY on sending a dummy PSK in case ( 2 ) , though I do n't think it 's a good idea for case ( 1 ) . The case that really matters here is when the outer and inner ClientHello both lack PSKs : Suppose the buggy network is sensitive to ( 1 ) and only allows ECH extensions when the outer ClientHello has a PSK because it knows those ca n't be ECH . That network has effectively broken all connections because the only way for the client to get a PSK is to have connected to the server without a PSK at some point . Suppose instead the buggy network is sensitive to ( 2 ) and breaks if the inner ClientHello has a PSK but the outer does not . The connect will fail , but between single - use tickets and bounded client session caches , the client will quickly exhaust its tickets and get out of case ( 2 ) . This is a performance issue , but the connections still work . ( Though , yeah , adding the option to send a dummy one might help there . shrug ) 
 I 'm not following the following point . Could you elaborate ? In any case , the case to mitigate ( 2 ) seems more compelling than the case to mitigate ( 1 ) , since ( 2 ) would look like non - compliance to an ECH - ignorant network . Would be curious to see what others think . 
 So I think the benefit of GREASE - like strategies is that broader breakages now are more noticeable than focused breakage later . More noticeable breakage is more likely to be fixed , and less likely to make it to the ecosystem in the first place . This applies to ECH GREASE by saying we want all ClientHellos to look like ECH was deployed , so the network is less likely to develop intolerances . Differences between GREASE ECH and actual ECH thus matter because the network be intolerant to something that we failed to simulate . ( 1 ) says that , in actual ECH , all outer ClientHellos have no PSK . In GREASE ECH , some outer ClientHellos have a PSK while some do not . If we were to translate that to actual intolerance , it would mean the network rejects outer ClientHellos without a PSK . But that would break everything , ECH or non - ECH , anyway because clients do n't send PSKs the first time [ ] they connect to a server . Clients only have PSKs to send the second time , and you ca n't connect a second time if you did n't connect a first time . Thus , even though ( 1 ) is a difference , it does n't seem that difference prevents us from noticing intolerance . Agreed that mitigating ( 2 ) is more compelling than mitigating ( 1 ) . [ ] First time overall , first time after a restart ( if sessions are n't persisted ) , or first time after a long break ( sessions expired ) . 
 I agree that ( 2 ) is more important . And I 'm fine with a " MAY / SHOULD send an outer dummy PSK if you are using ECH and have an inner PSK . " if we were to append on a dummy PSK , what do you think would be a suitable length ? ( Bikeshedding over that should be fun . ) As an aside , I wanted to drill in on this point : This seems true , if we 're assuming the the intolerance is " break the connection , " which I think is the right interpretation . But it occurs to me that there 's a slightly weaker form of misbehavior that s 's possible with ( 1 ): a network may learn information about when a given client uses ECH . This seems out of scope , but maybe something to keep in mind ? 
 Re length , I dunno leave it to the client to choose ? " Probably not very long . " Making that in scope sounds exceedingly difficult . For instance , for a given server , you might know that tickets issued today start with ( maybe the ID of today 's key ) , but synthesized dummy tickets wo n't match that . 
 Yep , no argument there . 
 Discussed in 110 : Will submit a PR that says " clients MAY send a dummy PSK if the inner CH uses a PSK . " 
 LGTM
Paragraph (version A):
ECH considers two types of attackers: passive and active.  Passive
attackers can read packets from the network.  They cannot perform any
sort of active behavior such as probing servers or querying DNS.  A
middlebox that filters based on plaintext packet contents is one
example of a passive attacker.  In contrast, active attackers can
write packets into the network for malicious purposes, such as
interfering with existing connections, probing servers, and querying
DNS.  In short, an active attacker corresponds to the conventional
threat model for TLS 1.3 RFC8446.
Paragraph (version B):
ECH considers two types of attackers: passive and active.  Passive
attackers can read packets from the network, but they cannot perform
any sort of active behavior such as probing servers or querying DNS.
A middlebox that filters based on plaintext packet contents is one
example of a passive attacker.  In contrast, active attackers can
also write packets into the network for malicious purposes, such as
interfering with existing connections, probing servers, and querying
DNS.  In short, an active attacker corresponds to the conventional
threat model for TLS 1.3 RFC8446.
Paragraph (version A):
Passive attackers with a known ECH configuration can distinguish
between a connection that negotiates ECH with that configuration
and one which does not, because the latter used a GREASE
"encrypted_client_hello" extension (as specified in grease-ech) or
a different ECH configuration.
Paragraph (version A):
Passive attackers without the ECH configuration cannot distinguish
between a connection that negotiates ECH and one which uses a
GREASE "encrypted_client_hello" extension.
Paragraph (version A):
Active attackers can distinguish between a connection that
negotiates ECH and one which uses a GREASE
"encrypted_client_hello" extension.
Paragraph (version A):
See dont-stick-out for more discussion about the "do not stick out"
criteria from RFC8744.
Paragraph (version B):
Beyond these primary security and privacy goals, ECH also aims to
hide, to some extent, the fact that it is being used at all.
Specifically, the GREASE ECH extension described in grease-ech does
not change the security properties of the TLS handshake at all.  Its
goal is to provide "cover" for the real ECH protocol (real-ech), as a
means of addressing the "do not stick out" requirements of RFC8744.
See dont-stick-out for details.
Paragraph (version A):
The only explicit signal indicating possible use of ECH is the
ClientHello "encrypted_client_hello" extension.  Server handshake
messages do not contain any signal indicating use or negotiation of
ECH.  Clients MAY GREASE the "encrypted_client_hello" extension, as
described in grease-ech, which helps ensure the ecosystem handles ECH
correctly.  Moreover, as more clients enable ECH support, e.g., as
normal part of Web browser functionality, with keys supplied by
shared hosting providers, the presence of ECH extensions becomes less
unusual and part of typical client behavior.  In other words, if all
Web browsers start using ECH, the presence of this value will not
signal unusual behavior to passive eavesdroppers.
Paragraph (version B):
As a means of reducing the impact of network ossification, RFC8744
recommends SNI-protection mechanisms be designed in such a way that
network operators do not differentiate connections using the
mechanism from connections not using the mechanism.  To that end, ECH
is designed to resemble a standard TLS handshake as much as possible.
The most obvious difference is the extension itself: as long as
middleboxes ignore it, as required by RFC8446, the rest of the
handshake is designed to look very much as usual.
Paragraph (version B):
The GREASE ECH protocol described in grease-ech provides a low-risk
way to evaluate the deployability of ECH.  It is designed to mimic
the real ECH protocol (real-ech) without changing the security
properties of the handshake.  The underlying theory is that if GREASE
ECH is deployable without triggering middlebox misbehavior, and real
ECH looks enough like GREASE ECH, then ECH should be deployable as
well.  Thus, our strategy for mitigating network ossification is to
deploy GREASE ECH widely enough to disincentivize differential
treatment of the real ECH protocol by the network.
Paragraph (version B):
Ensuring that networks do not differentiate between real ECH and
GREASE ECH may not be feasible for all implementations.  While most
middleboxes will not treat them differently, some operators may wish
to block real ECH usage but allow GREASE ECH.  This specification
aims to provide a baseline security level that most deployments can
achieve easily, while providing implementations enough flexibility to
achieve stronger security where possible.  Minimally, real ECH is
designed to be indifferentiable from GREASE ECH for passive
adversaries with following capabilities: 1.  The attacker does not
know the ECHConfigList used by the server.  1.  The attacker keeps
per-connection state only.  In particular, it does not track
endpoints across connections.  1.  ECH and GREASE ECH are designed so
that the following features do not vary: the code points of
extensions negotiated in the clear; the length of messages; and the
values of plaintext alert messages.
Paragraph (version B):
This leaves a variety of practical differentiators out-of-scope.
including, though not limited to, the following: 1. the value of the
configuration identifier; 1. the value of the outer SNI; 1. use of
the "pre_shared_key" extension in the ClientHelloOuter, which is
permitted in GREASE ECH but not real ECH; [[TODO: Remove this
differentiator if issue #384 is resolved by a spec change.]] 1. the
TLS version negotiated, which may depend on ECH acceptance; 1. client
authentication, which may depend on ECH acceptance; and 1.  HRR
issuance, which may depend on ECH acceptance.
Paragraph (version B):
These can be addressed with more sophisticated implementations, but
some mitigations require coordination between the client and server.
These mitigations are out-of-scope for this specification.