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

Ben Schwartz <bemasc@google.com> Sun, 22 March 2020 21:50 UTC

Return-Path: <bemasc@google.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 179563A0847 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2020 14:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SE5jIrsA-CJr for <tls@ietfa.amsl.com>; Sun, 22 Mar 2020 14:50:00 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 D77DC3A083C for <tls@ietf.org>; Sun, 22 Mar 2020 14:49:59 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id j17so11164298wru.13 for <tls@ietf.org>; Sun, 22 Mar 2020 14:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KlVRmRzSBv9bqCSwW/zZ8RCJ6tvPE6ouwbVDTwBcN1k=; b=B4ccdfSo2ZTfhX+9JsaGWlCmtDokmNmL9DdNXIIIfkK8mY5J44B7CTQ6krl9F2xfYh gQ3uvBqVtS7nkjm0jS3aee74DwbRgKPtl2rc3C4pvQeWVpcBA2Tw5u2rr/1wpeCM+qfW /hRF8m2Nb8jBRoaLseE8Ey8llPmMs4Q7aXr4wQ11a5I9u342w9KvreFsFHHZt44eKW0h GW0id63M9a5ozNruzNkPKY1iEUQyjUyGKf5wYKEAVGJ1HEACc2VH7kRhMPOBJ54L0BcX InYP3YjQq7LUQrtFWQCP6mr+fNtmneYTZC5VN15LK6plqo0LWLeCevVH/3WdLPV56wSV UvrQ==
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=KlVRmRzSBv9bqCSwW/zZ8RCJ6tvPE6ouwbVDTwBcN1k=; b=YZyZxSI1We6AKV1JuuiT+DZc4SKFhNzRTXAYjV7wHBQQi9dXWc3JJVOsWI+o1HX807 WVV0u/iPtwMc1yGr2K3MUgyu0e11g+/66Sx2CP30wC4qY1WobBeu7XoXDUOu0agCbqPA yiMRaY8p4W2/9qx0OewAGhQQPeuThSLpBtFFSxHVc8OiWFHLd1P+nZoSUbb6Q1LvhUqC 6sFwkG2+vcsr6ZPWvGq7hxnmbylqxCzvcay61Pcws7y43avJTguGp3zcOpCbzONlXslQ HZ93s2JQ0zvtQu47ORiMYXX2N8ZZCF5ZLohNWh9PSlRmsPRZnd6qDnKt+zb7BvztFCGC H3Lw==
X-Gm-Message-State: ANhLgQ01r4Ua3dhp64EJwa0spEOJm606bWNoTL/8jzTc2/c3/ybHX1Y2 zvWShJrt2LQhBPJRO/rpkbpWgvUpBM9SPbokgLGnYVTcbg4=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuRsP+MrWMJISNoEI8DmqjHau5PQHvUJWf6FCdK?= =?utf-8?q?KGgH/heT599XnAbpuTWdOSibRVcLhS4Crsb46+QzAuSFSpw=3D?=
X-Received: by 2002:a5d:6992:: with SMTP id g18mr26045255wru.426.1584913797728; Sun, 22 Mar 2020 14:49:57 -0700 (PDT)
MIME-Version: 1.0
References: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
In-Reply-To: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
From: Ben Schwartz <bemasc@google.com>
Date: Sun, 22 Mar 2020 17:49:45 -0400
Message-ID: <CAHbrMsDdxtPeyZhrCFDAq4kr3iXN=1Uc0c03_NZy1_iSw4cPLw@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000f4a96605a1787f7b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P8reGqBcYdJVVTHeIlY4pwYJwaA>
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:50:02 -0000

It might be helpful to have a more precise definition of "do not stick out".

Considering a passive intermediary on the network path who cannot see the
DNS path, I can think of a few different "not stick out" properties we
might want:

1. The intermediary cannot identify clients that support ECHO.
2. The intermediary cannot identify servers that support ECHO.
2a. ... based on the connection contents alone.
3. The intermediary cannot tell whether ECHO was actually used.
3a ... based on the connection contents alone.

ECHO currently does not have Property 1.
Property 2 seems unlikely to be achievable in practice.  By publishing an
ECHOConfig, the server reveals its support for ECHO to everyone.  Chris
also noted a way to probe directly for confirmation.
Property 2a seems to be the topic at hand.
Property 3/3a relies on GREASE.  Like Property 2, Property 3 is (normally)
easily broken by an intermediary with a database of published ECHOConfigs.
[*]

I'm OK with losing Property 2a.  However, Property 3a seems achievable and
potentially valuable.  Consider a network where most clients support ECHO
and use GREASE, but only a minority can actually fetch ECHOConfigs, e.g.
ECHOConfig fetching requires the user to change their DNS configuration.
An intermediary who wants to record all SNIs could block only the
connections that actually activate ECHO, forcing clients to revert their
DNS configuration change and reveal the SNI.  Limiting this blocking to
public names that the intermediary is aware of seems like a worthwhile
step, especially since these names can be rotated relatively rapidly
(~minutes).

Property 3a is compatible with a flag in the ServerHello, so long as the
flag says "ECHO in use" when actually GREASE is in use.  This could be
achieved by reporting "ECHO in use" whenever the SNI is not a Public Name
used by the server (assuming it is not an actual origin name), or adding a
"long term ID" field (at least 32 bits) to ECHOConfig that persists across
key rotations.

Perhaps a good approach would be a flag meaning "ECHO retry in use".
(Would it be safe to move "retry_keys" to the unencrypted extensions?)

--Ben Schwartz

P.S. Ideally, I still want Property 1.  I imagine it might be possible by
formatting the ECHO as 0-RTT data, as Christian Huitema and others have
discussed over the years.

[*] Actual ECHO ClientHellos to a server at some IP will have the Public
Name in the SNI field, whereas GREASE ClientHellos will have the origin
name there instead.  However, if the ECHOConfig Public Name is in fact a
valid origin, then (with sufficiently good GREASE) the intermediary is
unable to state with certainty whether any particular user visited that
domain, even if many users cannot actually fetch ECHOConfigs.  In the
extreme, a server could publish a slate of ECHOConfigs that name _all_ of
its domains as Public Names, so that seeing any of them in the SNI field is
not proof of anything.

On Sun, Mar 22, 2020 at 12:55 PM Christopher Wood <caw@heapingbits.net>
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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>