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

Jonathan Hoyland <jonathan.hoyland@gmail.com> Sun, 22 March 2020 21:48 UTC

Return-Path: <jonathan.hoyland@gmail.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 051203A0840 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2020 14:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6oq4aZ8rVAGt for <tls@ietfa.amsl.com>; Sun, 22 Mar 2020 14:48:44 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 99AB83A083C for <tls@ietf.org>; Sun, 22 Mar 2020 14:48:44 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id o3so7528506vsd.4 for <tls@ietf.org>; Sun, 22 Mar 2020 14:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7ivLkuica6CuY8JTpvOA+l7AyvWF1EmoBEVZsvw3izo=; b=A3pIFfkJAN3avRh00DQRaARPxDJloKOFQ2c6m4gJ6E+9hRER+ZxrWIDiawLYud0n4o BKCQwLQiOhBvBRr4ErThqvTQQoIktgM/V2TmO3QMSfleVTE+al2c/TxvPqCtZSwmc08m YyrJglK41gd4bVAsQX2NgqM7DHccRisqLY+0LFBGkr2TgjXPXy+jHMI5Dr6HKEnDLmZp dJGy63dO1/8oJhAUMaEuk+rvu2kltFzMF4Wk+fLO64eDiyDHvqR02m1izPGW5NRCeQiU IiBbXpXen1ToryteHXJZItDJgil4l+0l9+LycCNUg4uEfa+WzaY2P0zot3Q9K2BiBjW+ qdeQ==
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=7ivLkuica6CuY8JTpvOA+l7AyvWF1EmoBEVZsvw3izo=; b=ODA3sHM70NWqASDc7E+PyKg4iXLKszDPzv9mcjKJf1h1RYEZ4fwY5DGSaAbJn/2fEP 4cH36jxIgrdE+sria3ynXWzn0mwQW3rS/rbB+t5IJXbFIQbB4XFGskFMdwYJq+HdTmbA Jq5KpGxX5hniHzg+OvcVolrUmKvCkIx0x2t4u964MTTLsREDJ0cM0ZwundNSr0Zt6zDB qYkb7Ga7z81ucKLNgk+PV+EGOXBBA1TnCnj4q1NX8q8+YZeFCCdX2vmRSLIrFtLc649c B8ZwvPsPWjd4KhKEL9wBQ5Q8FuZL4SlFMd6UKdNgUGaG3TsKy153HpcGIjjaas/efOat p+sw==
X-Gm-Message-State: ANhLgQ0SSsIxQeUJgSi2pI9EfYZY9538xbX//iTkO14wkshbCK7CH76i /xkJyJGkBiGNvkaskAC0kY63yvUrUwyBqA4ev/S+2kcmmiQ=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vv6GvPTBzjdA7Fz+xP6G7MYvTQHCr703Xlbr1YD?= =?utf-8?q?Ka81GXdnUQXcVcPgKP+SOnZ/Eo4XVb1vSerxkAeIK9ea9Xw=3D?=
X-Received: by 2002:a67:8003:: with SMTP id b3mr12412007vsd.148.1584913723526; Sun, 22 Mar 2020 14:48:43 -0700 (PDT)
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
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 21:48:51 -0000

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
>