Re: [TLS] In support of encrypting SNI

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 15 May 2014 10:14 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 1D0E01A04A2 for <tls@ietfa.amsl.com>; Thu, 15 May 2014 03:14:41 -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 1rl46GViyxPA for <tls@ietfa.amsl.com>; Thu, 15 May 2014 03:14:39 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE41A049E for <tls@ietf.org>; Thu, 15 May 2014 03:14:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 59B30BE80 for <tls@ietf.org>; Thu, 15 May 2014 11:14:32 +0100 (IST)
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 To6CP9Ntp9ks for <tls@ietf.org>; Thu, 15 May 2014 11:14:32 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 358C6BE79 for <tls@ietf.org>; Thu, 15 May 2014 11:14:32 +0100 (IST)
Message-ID: <53749388.80009@cs.tcd.ie>
Date: Thu, 15 May 2014 11:14:32 +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: tls@ietf.org
References: <537448DD.7010806@accessnow.org>
In-Reply-To: <537448DD.7010806@accessnow.org>
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/qNe3XbThdeyDQWb8gg0MmMHTT0g
Subject: Re: [TLS] In support of encrypting SNI
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: Thu, 15 May 2014 10:14:41 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hiya,

One more thought for this thread before the meeting (for which
I'll unfortunately be remote and distracted but I'm sure you'll
have a good one).

Considering tempora, which we know is happening, (so handshake
bytes should be considered to be recorded with probability of
approx. 1.0), even a simple hash of the SNI could have some
limited value.

Say if the client sent "hash-algId,H(tolower(SNI)||stuff)"
or similar rather than sending just "SNI" (where "stuff"
is maybe something to distinguish http vs imap perhaps).

For the real server/router that's no deal at all assuming the
router isn't dynamically routing to any old DNS name used
in SNI. (Wouldn't that be a lovely DoS vector.)

For the tempora attackers it'd mean they can no longer just
do "select * from tempora_db where sni like %victim%" (pardon
my SQL which is probably wrong;-)

Now that might just be an irritant, and not that effective
given the adversary can build up tables but I think it is
an attack that we do need to specifically consider since
we *know* the recording of those bytes is happening.

And of course if we had a structure like "f-algId,f(SNI)"
then other algs (e.g. encrypt with public key from DNS)
could be added later if we can't use 'em now, so even
adding this minimal bit of "protection" might provide
the right hooks for later, better work.

A workable SNI encryption scheme is of course what we'd
like, and would blow the above out of the water, but if
we don't find a workable SNI encryption scheme now, there
might be reasons to think about the structure above and
there are definite reasons to think about tempora as an
attack.

Cheers,
S.

PS: To be clear, I'm more arguing for considering the
tempora attack here and maybe for the structure and am
not really a fan of a simple hash.
And #include <hatstatement> as usual.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTdJOIAAoJEC88hzaAX42iW/QH/jDJ3ggmqFv74vh34p46UPyJ
35Ztq31db6DYA70ianiXdEi1+w1QJVTaGymeff3wCaEQgpPEvaCOR1itJEMNAuoe
WlaJjWCOqougL6fMpLgpt4bruGs07kEnw6LJPCAGzyCb2sZ2cyyrdf/euPAcq0DD
YDN1BRwhRx/EHPuWHWxFS+m9fGMefJml6VkenFEUi0DIcseb7SOSbxeU/Ywe22uE
uGo/lKLip7obsmLCSECdldMuqPvA+Fa4r1lAed3Qx6ApwCUnqoZVxwPc1FoxfNwj
7A8hiw6bFpe5PmSzwfN9AxZch/FnkajzDEy8+Lm9hMZGnLWn2jxpRMk9Q/lW5a8=
=nhuj
-----END PGP SIGNATURE-----