Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

Ralf Skyper Kaiser <> Tue, 19 November 2013 11:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F210A1ADAEA for <>; Tue, 19 Nov 2013 03:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kexha3JX_iSC for <>; Tue, 19 Nov 2013 03:46:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::22a]) by (Postfix) with ESMTP id 493F51AD8EA for <>; Tue, 19 Nov 2013 03:46:13 -0800 (PST)
Received: by with SMTP id qd12so1625842ieb.29 for <>; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TrhNZmw2LceXbIrCDUe/NCOgVKKOo79C5+8UniFDWXs=; b=dhzO+f97iCjozgv/kNZ44tecIo9cp6Z5LahvGYtlJSJ1w2CWagAle2cRMqi5gE3Hi6 Sz3NOGPqtAGm/sQHW1N2XAsCEROXhVlvXiQ5bj3QaTcber0b8inFWUMw0P1Q+ruPa/Q9 /4x3/9EE281md7ZrAjNVIGTvret+STyyX9o2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TrhNZmw2LceXbIrCDUe/NCOgVKKOo79C5+8UniFDWXs=; b=ibOTepxORAUbRZj5TyurzgpKTNnc+EBqDRQZNpikzdvCbzZSRdgiP4+ztxQZjN+F2R i7MkhDU62xYTZBzQtB1mrKoF3jA9ukLcMvmiCZEk4EZ24PWaWuFoWt9xaMMCu51bUTgS Tpdu4OVvSv8fj4xObEyiH2Mg3yuzNPLm9EzySiyczU+rXSOryXYaLfAb5ehhwmYODviM rxvbUBJVrjgzVB92IfyBuSfAqyousfjIBDWb19eCLqsYT6CVW6APXUWeJ+ZFPq0zKP03 gC7q82qhRpWH6vIKtToYX5n1Jo99rLBNgaVSluLi0EqQtdEKtpQJJEytZaGyxmw6fdGm mVWw==
X-Gm-Message-State: ALoCoQmH+fhmjsjhIFr/lbzBs4EcAs7SqhEoG2ltqakHSJngV+60Js3y9fWEV+WQm69AMWb3EBo6
MIME-Version: 1.0
X-Received: by with SMTP id im10mr334874icb.46.1384861567283; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
Received: by with HTTP; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Tue, 19 Nov 2013 11:46:07 +0000
Message-ID: <>
From: Ralf Skyper Kaiser <>
To: "" <>
Content-Type: multipart/alternative; boundary=001a11332dbcc8063d04eb8635d6
Cc: "" <>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-Mailman-Version: 2.1.15
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: Tue, 19 Nov 2013 11:46:15 -0000

Hi Martin,

On Tue, Nov 12, 2013 at 9:41 PM, Martin Rex <> wrote:

> Ralf Skyper Kaiser wrote:>
> > 2. The attack that you describe requires active packet injection.  We
> just
> > increased the cost for the attacker from passive recording of data to
> > active packet injection. Active packet injection does not scale and is
> > detectable. The proposed solution solves pervasive surveillance. That's
> the
> > goal.
> You're misrepresenting the issue.  For a passive observer, i.e. someone
> watching the media where the connection data travels, inserting a
> fake IP datagram with TCP RST in it is **TRIVIAL**, i.e. the cost is
> infinitesimal close to zero.  A man-in-the-middle requirement would
> be real cost, but we do not have that here.

It is technically trivial to insert a TCP RST. It is a whole different
matter in real life. For example does
the US operate under a certain policy that allows for passive monitoring
but would only allow
for active packet injection (TCP RST) under special circumstances.

The claim stands: With encrypted SNI we just raised that bar for pervasive
surveillance. Not just the technically
(doing millions of TCP RST's on every TLS 1.3 connection - undetected - is
not as easy in the real world as you say it
is - especially the undetected part) but also policy wise do we raise the

> >
> > I hear you loud and clear that you wish for a protocol where the SNI is
> > transmitted encrypted _and_ without the attacker
> > being able to reveal the SNI during an active attack. I'm certain that a
> > proposal by you of how to do this would be highly appreciated and
> > educational to the readers.
> I never said that.
> What you seem to be looking for is a protocol where an observer does not
> know which parties are talking.  That will either require fully dynamic
> addresses for both communication peers, pre-shared keys and out-of-band
> protected&secure discovery where to find the dynamic address of the
> communication acceptor.  Or require the use of a bunch of third parties
> like a TOR network, which will hide who is talking to whom.

No. Not at all. What I'm looking for is encrypted SNI and the browser to
stop advertising
in advance which server I'm connecting to. (On a side note there is a lot
of work
progressing in the DNS community for making DNS confidential. Now is the
time to
fix the last leg that leaks the domain name: SNI).

> This is not something you can solve with a few tweaks of the TLS protocol.
> And may get the consumers of TLS in big trouble if you continue boasting
> that you could achieve this, because some might fall for this myth.

It fact it can be solved with a tweak in TLS 1.3. See Eric's IETF88



> -Martin