Re: [TLS] About encrypting SNI - Traffic Analysis Attacks?

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 13 May 2014 21:15 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 234291A01FE for <tls@ietfa.amsl.com>; Tue, 13 May 2014 14:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 l_b_g6zRuxQj for <tls@ietfa.amsl.com>; Tue, 13 May 2014 14:15:45 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 488461A01C9 for <tls@ietf.org>; Tue, 13 May 2014 14:15:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7141EBE6F; Tue, 13 May 2014 22:15:38 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLMXEgIU3jxG; Tue, 13 May 2014 22:15:37 +0100 (IST)
Received: from [10.87.48.12] (unknown [86.46.28.248]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7A39BE80; Tue, 13 May 2014 22:15:36 +0100 (IST)
Message-ID: <53728B78.30306@cs.tcd.ie>
Date: Tue, 13 May 2014 22:15:36 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>, Michael StJohns <msj@nthpermutation.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <D2CB0B72-A548-414C-A926-A9AA45B962DA@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <CACsn0cmusUc3Rsb2Wof+dn0PEg3P0bPC3ZdJ75b9kkZ5LDGu_A@mail.gmail.com> <534DB18A.4060408@mit.edu> <CABcZeBOJ7k8Hb9QqCAxJ_uev9g_cb4j361dp7ANvnhOOKsT7NA@mail.gmail.com> <CA+cU71kFo6EihTVUrRRtBYEHbZwCa9nZo-awt4Sub2qXcKHC7g@mail.gmail.com> <CAK3OfOi1x9huaazwcO=d72mfOFuV_RyXnfHmFRduhhbJE2miYw@mail.gmail.com> <CALCETrWukS2QJSb01n7OpXD2iaK43OhZr4E8YZyJ6JaorCdBKw@mail.gmail.com> <CAKC-DJjgFrAmxkC-MsmL+-uRWpN_mDPGkV_g-6DhbVH+69EQEQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <53727940.2070900@nthpermutation.com> <CAK3OfOhcCJ2h=MhRFKLedOsxZeMk94C2sETkx3h6HzG7JeW=Jg@mail.gmail.com>
In-Reply-To: <CAK3OfOhcCJ2h=MhRFKLedOsxZeMk94C2sETkx3h6HzG7JeW=Jg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zuNzNGm3hOl88jmoiNGocJ34Cl0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks?
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, 13 May 2014 21:15:47 -0000

Hiya,

Just some thoughts on this... no hats and all that.

On 13/05/14 21:20, Nico Williams wrote:
> HTTP has infinitely extensible headers just for this purpose ;)

HTTP/2.0 is also adding padding, so it could be that a good
solution here for web sites depends on some or all of TLS1.3
and HTTP/2.0 and DNS-priv. That is quite a lot of moving parts,
but if we don't fully examine the SNI part of that story now,
then I can't see it happening again for a long time to be
honest.

I also don't like the "DNS is clear, so why not SNI" argument.
Because that goes on to "if SNI is clear, then why not ALPN?"
And if ALPN, then why not the server cert? Etc. etc. And
then in the end we lose out on lots of chances to counter
traffic analysis. (Not that we know so well how to do that,
but nonetheless...)

If the argument ends up being that nobody wants to implement
SNI encryption, then that's important, but I don't believe we
have a proposal so far that'd allow folks to decide that. (Or
maybe I missed it, I just saw some sketches in mails.) That
does however put the onus on those who would like to see this
done to write down how. If nobody does that, then I'd say
Rich's argument will win by default since he's pointing out
a real difficulty. I think that'd be a pity but doing better
depends on those who want to do better figuring out and
writing down how.

One other thought, maybe more optimistic: could it be that
there might be ways to protect things like SNI used for
routing the 2nd and later times you visit a web site, even
if TLS had to put the DNS name in clear (or close-to) first
time around? If one gets that property via some mechanism
or other, and if the hosts at which there's any point in
trying to hide SNI (those with lots of VirtualHost equivalents)
get lots of non-first time visits maybe even from the same
clients, and if DNS-priv happened, then maybe that'd be a
sufficiently useful answer. I'm not sure, but that's the
kind of analysis that needs to be done by someone interested
in countering traffic analysis. I really hope someone's up
for doing that kind of work.

S.