Re: [TLS] Dropping "do not stick out" from ECHO

Eric Rescorla <ekr@rtfm.com> Sun, 22 March 2020 22:15 UTC

Return-Path: <ekr@rtfm.com>
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 <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; Sun, 22 Mar 2020 15:15:03 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id i20so382354ljn.6 for <tls@ietf.org>; 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: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net> <35e8090b-99c8-0982-bb7b-79685fe68b6c@huitema.net> <CACykbs0EaJeKTHnSMjeRPSrmvruDdPNXcH5ba+84gQsdBGEURw@mail.gmail.com>
In-Reply-To: <CACykbs0EaJeKTHnSMjeRPSrmvruDdPNXcH5ba+84gQsdBGEURw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 22 Mar 2020 15:14:25 -0700
Message-ID: <CABcZeBM4nx0NYz-GvvADqvchZGhJxcG3rX94TRV-xmY+GyZKww@mail.gmail.com>
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000092974e05a178d90e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2dfxvLUkxp35N12lZNev0eGy5eQ>
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Mar 2020 22:15:07 -0000

On Sun, Mar 22, 2020 at 2:49 PM Jonathan Hoyland <jonathan.hoyland@gmail.com>
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 <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
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>