Re: [TLS] DNS-based Encrypted SNI

Eric Rescorla <ekr@rtfm.com> Wed, 04 July 2018 16:54 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 5D4D5130F04 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 09:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 1eNxAWeoNOQz for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 09:54:14 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 04DE7130E80 for <tls@ietf.org>; Wed, 4 Jul 2018 09:54:12 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id x10-v6so2278993ybl.10 for <tls@ietf.org>; Wed, 04 Jul 2018 09:54:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lRSFfqijJ+hz3BOumRCf8a+gCOmsLKId7GHm7yJ+zXA=; b=eYU1BBRsOeSMF6Utz1t01cI+9v4DFzD3RIoEnhlc5Nj90whW97N2KRuNU9oz5UQbcC EQGV7FZaZ19KPYkxFSgxQfi2bWcqoY+J2QHkDYPpMgedtpFEvVIBmXu2/zXSC8eAqsQP qcZ8+q5gpT6kBtiypoOGoFmSdk1/Td12Q35M8ULXec2c/BY5/gEV7810C8PP0zgphrnH mqq39tVDT6pYx9TOdwi9OLwoLCLSk2C2FOdHcMeKdcJY3U0nQ/cgg+r655iTY4OvTSuv QUffSyb1aGUkpi9IxeUStR0iXdW55gvleKwgnIZrYyil6teZt/oUcmKRTMgqDo2yItgU tR7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lRSFfqijJ+hz3BOumRCf8a+gCOmsLKId7GHm7yJ+zXA=; b=JkjDXxGXWvrN9j0BkrJe3GwcTy3faT77zDHRBryWNJmxyX8vbZWYAii0UWbU25i+CW TIkPIjlF5SBl+5SlSsWTOt9QFoyhu2n07sTi00HNOuObppqPogsev57azYUYRhepdXeh F0pqWXx9YAUVq8F2V62ZI7d4O82Q3zO6yX4EM9vZv/wnb/d2J6Gn8zgQP7gpehXHzY/Z MHHJKqttLoZQOFo6jcNZ3N2z5onINrVLPM2oWYq8Yffi3ZEapIVf0Et5CH70pvmDDFqr obbkoh85PAZ0+piGTRmCEx5bqbgEKB0eOJwX4gD/zylWoEQ7CAG/Wt+VJ//xEOZHJC9K H4Qw==
X-Gm-Message-State: APt69E3H/crDW+98xMbYbe3aLMUHAIFyZ+EkRIRVuohwu1uR1AKEcmDG mEtKJIcQ9kjOb+rkVHQIB5vYLFnaHXSNX2aWXX0c5qBg
X-Google-Smtp-Source: AAOMgpfwop9LhMKr3Lsi4N2szu942GIYbSDpKxPsEmzeAJROsinXlggdkFaD2Fnyj4s2d8hRrRqq3AYGmranAX9rz0s=
X-Received: by 2002:a25:acd0:: with SMTP id x16-v6mr1503261ybd.407.1530723251286; Wed, 04 Jul 2018 09:54:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 09:53:30 -0700 (PDT)
In-Reply-To: <20180704130834.GB26089@LK-Perkele-VII>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com> <20180704044844.GB10665@LK-Perkele-VII> <CABcZeBNMqH5FU133qSHOehFDK5SCh1qZy8nk2Y1k-JQ5STJp+Q@mail.gmail.com> <20180704130834.GB26089@LK-Perkele-VII>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 04 Jul 2018 09:53:30 -0700
Message-ID: <CABcZeBMLnb+fK+ZQkp3P+BZW2XSc5pkJsF9dF+e49gyj=pVa_w@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a4889105702f4734"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TiY9yvQGXA9OMdlvSn-aUFy4JVE>
Subject: Re: [TLS] DNS-based Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 16:54:24 -0000

On Wed, Jul 4, 2018 at 6:08 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote:
> > On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> >
> > > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > > > I am working on an implementation for NSS/Firefox and I know some
> > > > others are working on their own implementations, so hopefully we can
> > > > do some interop in Montreal.
> > > >
> > > > This is at a pretty early stage, so comments, questions, defect
> > > > reports welcome.
> > >
> > > One thing I noticed: First there is this in evaluation:
> > >
> > > 7.2.4.  Do not stick out
> > >
> > >    By sending SNI and ESNI values (with illegitimate digests), or by
> > >    sending legitimate ESNI values for and "fake" SNI values, clients do
> > >    not display clear signals of ESNI intent to passive eavesdroppers.
> > >
> > > Is that suggesting to send fake ESNI values? If so, there is this in
> > > endpoint behavior:
> > >
> >
> > No, you would not send fake ESNI values. The idea here is that there is a
> > group of IPs (associated with a big provider, then all ESNI-supporting
> > clients will send ESNI to it. So the provider will stick out, but the use
> > of site X versus site Y on the provider will not    stick out. And the
> > provider's IPs are reasonably well known through other mechanisms, so
> this
> > doesn't tell you much. Of course, this does not help big sites that
> aren't
> > using shared infrastructure (e.g., Facebook), but I don't know how to do
> > that.
>
> What does "with illegitimate digests" mean then?
>

I didn't write this text, but I agree that it's in conflict with the
requirement that
you abort with an unknown key. We went through some design variants and
this looks like a remnant of a previous one.

-Ekr


>
> -Ilari
>