MIME-Version: 1.0
References: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
 <35e8090b-99c8-0982-bb7b-79685fe68b6c@huitema.net>
In-Reply-To: <35e8090b-99c8-0982-bb7b-79685fe68b6c@huitema.net>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Sun, 22 Mar 2020 21:48:32 +0000
Message-ID:
 <CACykbs0EaJeKTHnSMjeRPSrmvruDdPNXcH5ba+84gQsdBGEURw@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007d920405a1787b2c"
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tls/VAGTj0cirHOjjq3mCZM7QnycHL0>
Subject: Re: [TLS] Dropping "do not stick out" from ECHO
Precedence: list

--0000000000007d920405a1787b2c
Content-Type: text/plain; charset="UTF-8"

I'm worried that it'll be too tempting for orgs and Governments to just
drop sessions which have negotiated ECHO.
Even if we had wide scale deployment of GREASE, if a third-party can allow
GREASE but block successful ECHO handshakes then all the effort we've
expended will be wasted.

Does the probing attack only apply in cases without a key share, or is it
also possible in cases where key shares are in use?

Regards,

Jonathan

On Sun, 22 Mar 2020 at 18:00, Christian Huitema <huitema@huitema.net> wrote:

> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--0000000000007d920405a1787b2c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m worried that it&#39;ll be too tempting for orgs an=
d Governments to just drop sessions which have negotiated ECHO.<div>Even if=
 we had wide scale deployment of GREASE, if a third-party can allow GREASE =
but block successful ECHO handshakes then all the effort we&#39;ve expended=
 will be wasted.=C2=A0</div><div><br></div><div>Does the probing attack onl=
y apply in cases without a key share, or is it also possible in=C2=A0cases =
where key shares are in use?</div><div><br></div><div>Regards,</div><div><b=
r></div><div>Jonathan=C2=A0</div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Sun, 22 Mar 2020 at 18:00, Christian Hu=
itema &lt;<a href=3D"mailto:huitema@huitema.net">huitema@huitema.net</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
    <p>On 3/22/2020 9:54 AM, Christopher Wood wrote:<br>
    </p>
    <blockquote type=3D"cite">One
      of the original motivating requirements for ECHO (then ENSI) was
      &quot;do not stick
      <br>
      out&quot; [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&#39;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 href=3D"https://tools.ietf.org/html/draft-ietf-tls-sni-encrypt=
ion-09#section-3.4" target=3D"_blank">https://tools.ietf.org/html/draft-iet=
f-tls-sni-encryption-09#section-3.4</a></blockquote>
    <p><br>
    </p>
    <p>Section 5 of this draft says:</p>
    <pre>                                                              ... =
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=3D"https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#=
section-3.4" target=3D"_blank">Section 3.4</a> may have to be lifted, espec=
ially 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>
  </div>

_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</blockquote></div>

--0000000000007d920405a1787b2c--