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

Ralf Skyper Kaiser <skyper@thc.org> Tue, 19 November 2013 11:46 UTC

Return-Path: <skyper@thc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F210A1ADAEA for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kexha3JX_iSC for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:46:13 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 493F51AD8EA for <tls@ietf.org>; Tue, 19 Nov 2013 03:46:13 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id qd12so1625842ieb.29 for <tls@ietf.org>; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; 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; d=1e100.net; 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 10.42.224.10 with SMTP id im10mr334874icb.46.1384861567283; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <20131112214115.9095A1AA81@ld9781.wdf.sap.corp>
References: <CA+BZK2oGsu=yr0JtAro=KOu7YUbX0E_xNnkCwfiC2g0BDS61TA@mail.gmail.com> <20131112214115.9095A1AA81@ld9781.wdf.sap.corp>
Date: Tue, 19 Nov 2013 11:46:07 +0000
Message-ID: <CA+BZK2pT8wJyLLV1K4B4tq_Ay_06dYLXyu-AM=gtWd2Ax=77qA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: multipart/alternative; boundary=001a11332dbcc8063d04eb8635d6
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 19 Nov 2013 11:46:15 -0000

Hi Martin,



On Tue, Nov 12, 2013 at 9:41 PM, Martin Rex <mrex@sap.com> 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
bar.



> >
> > 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
presentation.

regards,

ralf

>
>
> -Martin
>