To: Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <tls@ietf.org>
References: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata=
 mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS
 HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO
 I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy
 IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ
 olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB
 AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC
 UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m
 VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf
 wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3
 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0
 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd
 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV
 CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG
 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ
 bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o
 G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y
 wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb
 LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c
 YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az
 tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w
 uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq
 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz
 BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT
 u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST
 Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7
 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw
 Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY
 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <35e8090b-99c8-0982-bb7b-79685fe68b6c@huitema.net>
Date: Sun, 22 Mar 2020 10:58:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
Content-Type: multipart/alternative;
 boundary="------------1782EAA687E42E6B703F048D"
Content-Language: en-US
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tls/qq-0z_FAIsp66dvK5UstITsAYUg>
Subject: Re: [TLS] Dropping "do not stick out" from ECHO
Precedence: list

This is a multi-part message in MIME format.
--------------1782EAA687E42E6B703F048D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/22/2020 9:54 AM, Christopher Wood wrote:

> One of the original motivating requirements for ECHO (then ENSI) was
> "do not stick
> out" [1]. This complicates the current ECHO design, as clients must
> trial decrypt
> the first encrypted handshake message to determine whether a server
> used the inner
> or outer ClientHello for a given connection. It's also trivial to
> probe for ECHO
> support, e.g., by sending a bogus ECHO with the same key ID used in a
> target client
> connection and checking what comes back.
>
> I propose we remove this requirement and add an explicit signal in SH
> that says
> whether or not ECHO was negotiated. (This will require us to revisit
> GREASE.)
>
> What do others think?
>
> Thanks,
> Chris (no hat)
>
> [1]
> https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.=
4


Section 5 of this draft says:

                                                              ... In
   practice, it may well be that no solution can meet every requirement,
   and that practical solutions will have to make some compromises.

   In particular, the requirement to not stick out presented in
   Section 3.4 <https://tools.ietf.org/html/draft-ietf-tls-sni-encryption=
-09#section-3.4> may have to be lifted, especially for proposed solutions=

   that could quickly reach large scale deployments.

As part of AUTH48 changes, we agreed to add a line in section 3.4
pointing to this comment is section 5.

We can observe that ECHO already sticks out, because of the presence of
an unexpected encrypted field in the Client Hello. So in practice ECHO
deployment already relies on achieve large scale deployment, and
possibly greasing the encrypted parameter.

-- Christian Huitema


--------------1782EAA687E42E6B703F048D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>On 3/22/2020 9:54 AM, Christopher Wood wrote:<br>
    </p>
    <blockquote type="cite"
      cite="mid:EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net">One
      of the original motivating requirements for ECHO (then ENSI) was
      "do not stick
      <br>
      out" [1]. This complicates the current ECHO design, as clients
      must trial decrypt
      <br>
      the first encrypted handshake message to determine whether a
      server used the inner
      <br>
      or outer ClientHello for a given connection. It's also trivial to
      probe for ECHO
      <br>
      support, e.g., by sending a bogus ECHO with the same key ID used
      in a target client
      <br>
      connection and checking what comes back.
      <br>
      <br>
      I propose we remove this requirement and add an explicit signal in
      SH that says
      <br>
      whether or not ECHO was negotiated. (This will require us to
      revisit GREASE.)
      <br>
      <br>
      What do others think?
      <br>
      <br>
      Thanks,
      <br>
      Chris (no hat)
      <br>
      <br>
      [1] <a class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4"
        moz-do-not-send="true">https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4</a></blockquote>
    <p><br>
    </p>
    <p>Section 5 of this draft says:</p>
    <pre class="newpage">                                                              ... In
   practice, it may well be that no solution can meet every requirement,
   and that practical solutions will have to make some compromises.

   In particular, the requirement to not stick out presented in
   <a href="https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4">Section 3.4</a> may have to be lifted, especially for proposed solutions
   that could quickly reach large scale deployments.
</pre>
    <p>As part of AUTH48 changes, we agreed to add a line in section 3.4
      pointing to this comment is section 5.<br>
    </p>
    <p>We can observe that ECHO already sticks out, because of the
      presence of an unexpected encrypted field in the Client Hello. So
      in practice ECHO deployment already relies on achieve large scale
      deployment, and possibly greasing the encrypted parameter.</p>
    <p>-- Christian Huitema<br>
    </p>
  </body>
</html>

--------------1782EAA687E42E6B703F048D--