Re: [TLS] ESNI GREASE - answer needed?

David Benjamin <davidben@chromium.org> Mon, 29 July 2019 23:58 UTC

Return-Path: <davidben@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 8E1F6120025 for <tls@ietfa.amsl.com>; Mon, 29 Jul 2019 16:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.251
X-Spam-Level:
X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 xbfl6Sl6jTD3 for <tls@ietfa.amsl.com>; Mon, 29 Jul 2019 16:58:45 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 160CE12002E for <tls@ietf.org>; Mon, 29 Jul 2019 16:58:45 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id a15so61265137qtn.7 for <tls@ietf.org>; Mon, 29 Jul 2019 16:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g3QcG687+7HsCLiHR4YTt0uo3JEitScaaO9b8VKJXNc=; b=KoxBFFoYIYkTZqvPYynlltEZkj0FIsKI2te3R4uORTUFAWHSa5hlYD4gEFA2WGer2h x1bSYaFoR+60EASk8HRbIvc61PFcZYWJfpFWDkowtmTZwVSaprSx8ImRip33Ex75tKga vCN9EcUmlWCq+Jc/hV2QQ63jRT2AwZlKBWkhM=
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=g3QcG687+7HsCLiHR4YTt0uo3JEitScaaO9b8VKJXNc=; b=EJ4/BCyFZGGTN38FVg6WOi122s8ZkfDmhH5JEalQfAEh3DKQ2SMQxh2smPMOCPnsmM +v8ZSQuY26qu6TqW4K3FuRq4wC3BIZmHHDPMPWb688NpCmiIb83HNh+Se/rifj/wPB5E PhnL9vnY/7GHSytMpyJlHk26EPKSJ1X3HLI4B22BaVSgu0D1jgsxPjl1ELvyH91TBQ0w lD7LR2Idgvu2hH376mO+FUjT2+fXwMlpg4bhhFwceltUtM2PKlk2Hcl+vT11q5c8cVju Q+i0CEeyQW7575JFT5KvoICGW9EWGs7cu5zj+qc8IuF7ZQXhCMmBhwjYZ1Zjj54U1Ers fkkg==
X-Gm-Message-State: APjAAAVtJd1Oa6R019z0snqQJndN5OoyCKNMBVZVui4VR6Hy2sbyOGIv IBvqjJ1dWWQtumxPZ2syrOYOt56vVHD+Z7emUunO
X-Google-Smtp-Source: APXvYqwT9bYip/cHBPFx9xPonXKhIg2H42+YDYtCNW59+24DzIYMg9RWjAWf4Ove7v2qNf6vzWd0oPVGwg3VmUis/tk=
X-Received: by 2002:ac8:38a8:: with SMTP id f37mr79924671qtc.150.1564444723837; Mon, 29 Jul 2019 16:58:43 -0700 (PDT)
MIME-Version: 1.0
References: <8c903f04-7605-be98-5813-688d1ef88c55@cs.tcd.ie> <4b2de58d-1957-ca48-59ab-521e7a5b510f@cs.tcd.ie> <CANduzxAZxzniBstSkUdtFz9sv6m2H7Ak+Gqt5TpxO9YqQM5pqw@mail.gmail.com> <67e69531-69a2-24e3-c2e7-d95054a3382d@cs.tcd.ie> <CANduzxCj67Aw9BLA7TkcXgWisE7ERZ4FC3yPW2DrtfQE7c-BEA@mail.gmail.com> <6a678b80-6233-552d-4755-db0d194fc49c@cs.tcd.ie>
In-Reply-To: <6a678b80-6233-552d-4755-db0d194fc49c@cs.tcd.ie>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 29 Jul 2019 19:58:27 -0400
Message-ID: <CAF8qwaDs-7CTLgq-tC=oE7RErb4y2LTso4Ocq51hupGQThtVVg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Steven Valdez <svaldez@google.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000009637e058edaaca6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ipur9g0oEVGncjUOt2LhYfqyNVE>
Subject: Re: [TLS] ESNI GREASE - answer needed?
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: Mon, 29 Jul 2019 23:58:47 -0000

I think the GREASE bits still need more work to avoid sticking out[*], but
you're right that there's a length leakage. But, rather than 50:50 of 16
bytes and ESNIKeys, I think it's better to pad all three cases up to an
ESNIKeys size. Whether this is done via bespoke padding within the ESNI
extension or the existing record-level padding, I don't have strong
opinions. With the server Certificate message, the draft currently just
says to pad at the record layer, so that would be consistent here too.

Additionally, the exact sizes of the TLS messages also needn't be so
obviously leaked. Servers can and should pack EncryptedExtensions,
Certificate, CertificateVerify, and Finished together into fewer records,
likely just one. This is worthwhile independent of ESNI. An encrypted
record is 22 bytes of overhead, so packing four messages into one record
saves 66 bytes. I don't know about other implementations, but BoringSSL
already does this. Of course, unpadded, an attacker that knows the expected
size of the other messages for a particular server can recover the
EncryptedExtensions length, so this isn't perfect.

[*] I filed https://github.com/tlswg/draft-ietf-tls-esni/issues/177 last
week with a sketch of an idea. Steven or I should hopefully have a more
concrete PR later.

On Mon, Jul 29, 2019 at 7:03 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hi both,
>
> On 29/07/2019 23:52, Steven Valdez wrote:
> > Without GREASE, a server who doesn't have keys can't respond with any of
> > the existing responses (esni_accept is wrong since it can't decode the
> > ESNI, esni_retry_request is wrong since it can't provide keys for the
> > client to use on the retry). The only valid response would be a new
> record
> > type that says it doesn't support ESNI, which becomes equivalent to just
> > not sending the ESNI extension back in the EncryptedExtensions.
> >
> > With GREASE, I don't know if it's particularly useful to fake the
> response
> > in the EncryptedExtensions, since network adversaries won't be able to
> see
> > the contents, I suppose its presence might slightly change the size of
> the
> > encrypted payload, though record padding could prevent that.
>
> Right it's the size that matters;-) I don't care if that's via
> this extension or not. ISTM that yes, producing a response to
> greased ESNI that doesn't stand out is an accepted requirement.
> And for the case in point, I think (but don't claim to be right)
> that a 50:50 distribution of ~16 payload octets or else
> ESNIKeys-sized things seems right.
>
> On 29/07/2019 23:53, Ben Schwartz wrote:> It sounds like you're asking
> for a middle ground for servers between
> > "supports ESNI (and has ESNIKeys)" and "doesn't support ESNI".
> > Maybe you  could explain the utility of this middle ground?
> >
> > From my perspective, I'd rather encourage real implementations
> > of ESNI than enable fake ones.
>
> Agreed. Not that documenting a corner case is encouraging
> the corner case of course:-) That seems more like being as
> complete as one can.
>
> I suspect this is more an issue about what code to write for a
> server instance that boots but hasn't yet gotten the values for
> ESNIKeys loaded for whatever reason. Or where disk access fails
> for a while. Or where... <insert weird case here>, but the server
> code still has to do something.
>
> Cheers,
> S.
>
>
> >
> >
> > On Mon, Jul 29, 2019 at 3:34 PM Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> > wrote:
> >
> >>
> >>
> >> On 29/07/2019 23:32, Steven Valdez wrote:
> >>> A server that doesn't have ESNI keys configured shouldn't be responding
> >> to
> >>> ESNI and should instead just ignore the ESNI extensions (as if it
> didn't
> >>> know what it was).
> >>
> >> Why?
> >>
> >> Thanks,
> >> S.
> >>
> >
> >
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>