Re: [TLS] Encrypted SNI

Ben Schwartz <> Wed, 04 July 2018 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13828130E52 for <>; Wed, 4 Jul 2018 08:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vo60G-8ut2ek for <>; Wed, 4 Jul 2018 08:37:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89E8F127AC2 for <>; Wed, 4 Jul 2018 08:37:37 -0700 (PDT)
Received: by with SMTP id v83-v6so8540418itc.3 for <>; Wed, 04 Jul 2018 08:37:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oLprrGRQSLFuee466IZ3naEpUFzsRUZ/Qg1ZWPTu8H4=; b=Z+k1qFLy2BZ8DCuwRFHxEay7ogYk+muAop6bWhyZuQY6adD64efidIPYoZd2avsIXZ qOC0igBWJfxWZQE79q3DIkzUpG8zImBTtvmqnklcGNiE+hZ+y8p5TdStG+yScl4GNRGq LzGaHrhSEYon1i35xCNDzFCNy/xpDzEGcuJPB8/N9yi9dhoyo6b4NLf9jBw/gVSht5wH JbYVOXda1kRsclZkV/dYsiIcRfK5/uOP7Tftcfy0l9yg5rvNSCoFeoe/xdqKvnPihjIM FTo21Gx+iqpEISI/2/mBAhLgn0kbKUAfO8NtFXw2txsh/zZNbP8DDMGhIyBaQyWtAwm+ i8cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oLprrGRQSLFuee466IZ3naEpUFzsRUZ/Qg1ZWPTu8H4=; b=PtYgbvu8Rlxl3UPIezAhB+Qq8KO5bHB0CcvliB2C58E63TwUhhwi697S5pxpPJhDdo Mv/mDz2mZ4c6EX+rtAw6RLKwybNYn/aACXJZRecVptKVqMdbRA847FMXklS/2uzjIiwX J/9b8A6ac8+D1UKsVFcXkZ60kGAjjOPg/Y4eO15ITWgfKu21YGAFIflb7Ha0jkTQ0efH aqQBwFD8bN0QSV77HJzruXWfoqayBgQBnYfsLz0eMjGblsWiOWdekBL9fUQnDRkGjT5B ct10bjcBiVk1Q7CSCcvEqCxr0I9ngdhhw3FhwV+Nw65jj2eqemHrhYAoIDtM4roFI49n JTjw==
X-Gm-Message-State: APt69E1/R0z8uXHluyKeMqm5GgrCOcEljBDp775SSUe41Mlsuxpi6W+N 6XTVs3Ca4OMsYvubvXuG83twWGid7/MlqGherg7gt/E/uJY=
X-Google-Smtp-Source: AAOMgpfy29IQv2yaqaqWGHsrjD72vpwTnqfKkYeqqclV+Ras0eH6IECY8W4WoMTcc7J52stqTYHsdP1YebdmDIjswKE=
X-Received: by 2002:a24:c903:: with SMTP id h3-v6mr2175217itg.87.1530718656438; Wed, 04 Jul 2018 08:37:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <20180703222414.17ee820c@computer.lan> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 4 Jul 2018 11:37:25 -0400
Message-ID: <>
Cc:, "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ce52c905702e3525"
Archived-At: <>
Subject: Re: [TLS] Encrypted SNI
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Jul 2018 15:37:42 -0000

On Tue, Jul 3, 2018 at 5:19 PM Brian Sniffen <bsniffen=> wrote:

> Hanno Böck <> writes:
> > So-called "Enterprise" infrastructure has delayed the work of this group
> > for at least a year. Noone of the people creating that mess has reached
> > out to this group to explain why they constantly break TLS - let alone
> > apologize for it.
> >
> > I believe there's a large overlap of the actors breaking TLS with the
> > actors who are worried about things like SNI encryption. I'm not sure I
> > see any reason not to consider these actors as anything but opposed to
> > the work of this group.
> Whoah!  I've been involved for years specifically to ask for care about
> encrypted SNI.  I don't know whether I break TLS; maybe opinions vary.
> But my concerns have been specific:
> First, at the engineering level, a requirement that servers do expensive
> cryptographic work in response to a first packet *and* an inability to
> charge that work to a user or application is a big problem.  It makes it
> too hard for users or applications to share a server, or leads to levels
> of address waste expensive even with IPv6.
> If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... then
> Encrypted SNI is a hard engineering problem!
> Second, at the architectural level, a serious question about whether
> this actually helps anybody, and if so whom?  I think the case of the
> Amnesty International worker in an oppressive dictatorship is almost
> certainly *not* helped by this work---see my questions about how many
> bits of security this provides against an adaptive adversary from this
> morning---and would like some clarity that this is about inhibiting the
> ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying
> with user sessions.
> My concerns at the engineering level have been welcomed, recognized,
> validated, and addressed.  Not always exactly the way I'd like, but
> absolutely addressed in a way that's appropriate and sincere.  I saw the
> same with requests to re-insert RSA Kx late last year.  The PATIENT
> folks have gotten a fair hearing.
> My architectural concerns have been heard, somewhat less eagerly.  Some
> participants, including our colleagues who are vendors to enterprises
> and folks like Ben Schwartz, have been clear that they will not bring
> all their motivations and evidence to the table.

It's always exciting to see your name in print.  Is there something I can
do to help here?  I honestly have no idea who "folks like me" are, or what
we did that gave you this impression.

> I significantly
> discount their arguments and expect others to do the same---but not to
> zero.

This is pretty disheartening.

Always happy to discuss in person.  I'll be at the meeting in Montreal.

It means we need to check their work as we go, or actually trust
> them as people, but it *can't* be harder than keeping NSA/IA people on
> Anyway, I think the PATIENT folks concerns about the engineering of TLS
> 1.3 have been heard, have been taken seriously, and have been
> addressed---same as mine or yours.  What I've seen of the architectural
> concerns leading to network-centric management and "tap" devices come
> down to claims about changes in architecture being too expensive,
> middleboxes being too expensive, changes to applications being too
> expensive, and general citation of an architecture only a few years old
> as immutable tradition.  Those claims have also been heard, plenty of
> folks have respectfully and diligently combed through them for evidence,
> and we've moved on.
> I bet that's frustrating and frightening for the folks writing from a
> world where those claims aren't faith-based---they're obvious.  They
> don't need citation any more than "China is a country"[1] needs
> citation.  Nonetheless, engineering conversations based on
> data-supported arguments continue to be welcome.
> -Brian
> Footnotes:
> [1]
>      but see also
> --
> Brian Sniffen
> _______________________________________________
> TLS mailing list