Draft: draft-ietf-tls-esni

Commentary: This addresses . cc 
 This looks fine , though I 'll note that since an HTTPSSVC record is public and the outer ClientHello record is public , it 's not unreasonable to pull values from there to put in the public fields since the observer already knows ( or can get ) them . Restricting them to come only from the ECHOConfig seems unnecessary . I think the key observation in this PR is that the outer ClientHello is n't really offering to establish a TLS connection -- it 's a not - crazy - looking wrapper for the actual ClientHello inside the ECHO extension , and the vehicle for the recovery flow . The only things a server can legitimately do are respond to the inner ClientHello or do a recovery handshake . Thus , most of the things you might set on the outer ClientHello are irrelevant ; they can be chosen to look innocuous , chosen at random , or copied from the inner ClientHello as the implementation chooses . 
 does this seem reasonable to you ? 
 Seems reasonable .
Paragraph (version A):
The TLS WG has extensively studied the problem of protecting SNI, but
has been unable to develop a completely generic solution.  I-D.ietf-
tls-sni-encryption provides a description of the problem space and
some of the proposed techniques.  One of the more difficult problems
is "Do not stick out" (I-D.ietf-tls-sni-encryption; Section 3.4): if
only sensitive/private services use SNI encryption, then SNI
encryption is a signal that a client is going to such a service.  For
this reason, much recent work has focused on concealing the fact that
SNI is being protected.  Unfortunately, the result often has
undesirable performance consequences, incomplete coverage, or both.
Paragraph (version B):
The TLS WG has extensively studied the problem of protecting SNI, but
has been unable to develop a completely generic solution.  I-D.ietf-
tls-sni-encryption provides a description of the problem space and
some of the proposed techniques.  One of the more difficult problems
is "Do not stick out" (I-D.ietf-tls-sni-encryption, Section 3.4): if
only sensitive/private services use SNI encryption, then SNI
encryption is a signal that a client is going to such a service.  For
this reason, much recent work has focused on concealing the fact that
SNI is being protected.  Unfortunately, the result often has
undesirable performance consequences, incomplete coverage, or both.
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.  All TLS notation comes from RFC8446; Section 3.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.  All TLS notation comes from RFC8446, Section 3.
Paragraph (version A):
A list of extensions that the client can take into consideration
when generating a Client Hello message.  The purpose of the field
is to provide room for additional features in the future.  The
format is defined in RFC8446; Section 4.2.  The same
interpretation rules apply: extensions MAY appear in any order,
but there MUST NOT be more than one extension of the same type in
the extensions block.  An extension may be tagged as mandatory by
using an extension type codepoint with the high order bit set to
understand must reject the ECHOConfig content.
Paragraph (version B):
A list of extensions that the client can take into consideration
when generating a ClientHello message.  The purpose of the field
is to provide room for additional functionality in the future.
See config-extensions for guidance on what type of extensions are
appropriate for this structure.
Paragraph (version B):
The format is defined in RFC8446, Section 4.2.  The same
interpretation rules apply: extensions MAY appear in any order, but
there MUST NOT be more than one extension of the same type in the
extensions block.  An extension can be tagged as mandatory by using
an extension type codepoint with the high order bit set to 1.  A
client which receives a mandatory extension they do not understand
MUST reject the ECHOConfig content.
Paragraph (version A):
A more serious problem is MITM proxies which do not support this
extension.  RFC8446; Section 9.3 requires that such proxies remove
any extensions they do not understand.  The handshake will then
present a certificate based on the public name, without echoing the
"encrypted_client_hello" extension to the client.