Re: [TLS] DNS-based Encrypted SNI

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 04 July 2018 13:10 UTC

Return-Path: <ilariliusvaara@welho.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 55C69130E7F for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 06:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 gYeNX6Oa5XXz for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 06:10:07 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7831277D2 for <tls@ietf.org>; Wed, 4 Jul 2018 06:10:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 3AC2047C9D; Wed, 4 Jul 2018 16:10:05 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id YKQc6y-oGwXF; Wed, 4 Jul 2018 16:10:05 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id AB11072; Wed, 4 Jul 2018 16:10:02 +0300 (EEST)
Date: Wed, 4 Jul 2018 16:08:34 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20180704130834.GB26089@LK-Perkele-VII>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com> <20180704044844.GB10665@LK-Perkele-VII> <CABcZeBNMqH5FU133qSHOehFDK5SCh1qZy8nk2Y1k-JQ5STJp+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBNMqH5FU133qSHOehFDK5SCh1qZy8nk2Y1k-JQ5STJp+Q@mail.gmail.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/p7Wayco26pg6aSkEY9IWGGCdkZs>
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 13:10:10 -0000

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?



-Ilari