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-----
- [TLS] In support of encrypting SNI Dan Blah
- Re: [TLS] In support of encrypting SNI Salz, Rich
- Re: [TLS] In support of encrypting SNI Seth David Schoen
- Re: [TLS] In support of encrypting SNI Stephen Farrell
- Re: [TLS] In support of encrypting SNI Watson Ladd
- Re: [TLS] In support of encrypting SNI Michael Carbone
- Re: [TLS] In support of encrypting SNI Fabrice
- Re: [TLS] In support of encrypting SNI Christian Huitema
- Re: [TLS] In support of encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] In support of encrypting SNI Robert Ransom
- Re: [TLS] In support of encrypting SNI Stephen Farrell
- Re: [TLS] In support of encrypting SNI Marsh Ray
- Re: [TLS] In support of encrypting SNI Watson Ladd
- Re: [TLS] In support of encrypting SNI Martin Rex
- Re: [TLS] In support of encrypting SNI Watson Ladd
- Re: [TLS] In support of encrypting SNI Martin Rex
- Re: [TLS] In support of encrypting SNI (off-topic) S Moonesamy
- Re: [TLS] In support of encrypting SNI (off-topic) Michael Carbone
- Re: [TLS] In support of encrypting SNI (off-topic) S Moonesamy