Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D5E3A08DB for ; Sun, 22 Mar 2020 15:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMU98ZMpRJDC for ; Sun, 22 Mar 2020 15:15:04 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9F93A08DA for ; Sun, 22 Mar 2020 15:15:03 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id i20so382354ljn.6 for ; Sun, 22 Mar 2020 15:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h/4za+VZYj+RCu3Um5T3DowwtlIxdwzF31MaHGtrqOM=; b=UyE3wdzKV0cwKcsIlX3HpjsbwB0JwnH8v7YM/hFW1MurJqQUjQ7gLHJ8s6hqe8/+W4 AMR/2fQLj+5Hlb1gU82MJ+0ZI5HCUtqr8+Co2Z3VLu53GBmaL7TdTVI9G+tUegwCEC7D lTb4eO9Ju161RBEh9hfC4kbWy474fxuMth5w8TYD7Z9UjUDWWb1M6wT+5nL3wX3/b4nf YnEjeoazKMQBdWfs6RPRFQsqXO3QFUNOqVuCu4Kn5R5erNm/UUUwA17C/EAzuXGvFh5u MH3PGLt+11ZXY/KZODXWlBaTdw/+oS2IY0xPIV/p8F8LiqbQEGNcIkgd9+vAvmiygGrV VJUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h/4za+VZYj+RCu3Um5T3DowwtlIxdwzF31MaHGtrqOM=; b=S+QeVRp4JhDDkRRu6HU46xq8pc3FLeW8z1kiJvi/6fTeQzgZ2qLYfbUZbfQIwtwrl7 Ua+C4rQEBQeaZcglQcoUY0TD65vOhbT4lqOkSp+9c6iWRbX+pvWSOlllHrmzWT1IJTzd lu6PEUAhuH2afiaSNspXTL8BfGb6CRDSvILQO9S1I5OrkhpHrrs4htBWExY4ppb3qS6y T8ExBm9Ig11qJtBC+qbidcx6yw5oQ9i160HtVZHe07r8MBF+MbTaVbiJc5bw+JzeFx+U CNYwAbrmC5oqSRippkx2jlb18Ke1qxQ2hKSTB/j3FmSgJ3ggm3mlZhW/whXM7PiPKxW0 XZsQ== X-Gm-Message-State: ANhLgQ1xm0pRegzX9zkC9afuCA4p1kdZXvE4UKMCjGuZBP+MvpJBO5Xi W0GKiIE5Y6MSw1PGewM0xMcwD/NYGRo9zAvb2XgfOg== X-Google-Smtp-Source: =?utf-8?q?ADFU+vuPuiGSdCM06QO6KCBWifpbuHAtMx2iKrzmnyQg?= =?utf-8?q?buuqkMM85p9hDwimp/kFETcR9rBzNaCjfsgq71FkBUYYYME=3D?= X-Received: by 2002:a2e:908f:: with SMTP id l15mr11290687ljg.120.1584915301959; Sun, 22 Mar 2020 15:15:01 -0700 (PDT) MIME-Version: 1.0 References: <35e8090b-99c8-0982-bb7b-79685fe68b6c@huitema.net> In-Reply-To: From: Eric Rescorla Date: Sun, 22 Mar 2020 15:14:25 -0700 Message-ID: To: Jonathan Hoyland Cc: Christian Huitema , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000092974e05a178d90e" Archived-At: Subject: Re: [TLS] Dropping "do not stick out" from ECHO X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 22:15:07 -0000 --00000000000092974e05a178d90e Content-Type: text/plain; charset="UTF-8" On Sun, Mar 22, 2020 at 2:49 PM Jonathan Hoyland wrote: > I'm worried that it'll be too tempting for orgs and Governments to just > drop sessions which have negotiated ECHO. > Well, those orgs will also be able to block encrypted DNS, without which ECHO is useless. We don't have an answer for this either. 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. > This seems like it needs more than a bare assertion. It's certainly the case that some entities will opt to block ECHO but many will not and the clients (and hence users) can be made aware of which ones do. -Ekr 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 > 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 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 >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000092974e05a178d90e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 22, 2020 at 2:49 PM Jonat= han Hoyland <jonathan.hoyl= and@gmail.com> wrote:
I'm worried that it'll be too temptin= g for orgs and Governments to just drop sessions which have negotiated ECHO= .

Well, those orgs will also be able = to block encrypted DNS, without which ECHO is useless. We don't have an= answer for this either.


Even if we had wi= de 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 w= asted.=C2=A0

This seems like it= needs more than a bare assertion.

It's certai= nly the case that some entities will opt to block ECHO but many will not an= d the clients (and hence users) can be made aware of which ones do.

-Ekr




Does the probing attack only apply in cases without a key share, = or is it also possible in=C2=A0cases where key shares are in use?

Regards,

Jonathan=C2=A0

On Su= n, 22 Mar 2020 at 18:00, Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20

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-iet= f-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 may have to be lifted, espec=
ially 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000092974e05a178d90e--