Subject: Re: [TLS] In support of encrypting SNI -- does IBE help with this problem?

From: Dan Brown <[email-masked]>
Date: Thu, 15 May 2014 14:00:03 +0000

Is using an ID-based encryption a possibility here? 

I haven't tracked this thread too closely, so I apologize if the TLS list
has already hashed through this idea. (E.g. maybe this is too
unconventional, etc.).

Anyway, in case you are still interested, here's one theoretical way it
might work, with pairing-based elliptic curve (with <.,.> operation):

Public values
G	generator
N	server name (hashed into group)
T	trusted authority public key
C	client ephemeral public key

Private keys 
c	client ephemeral private
r	client random key
t	trusted authority private
n	server name private

Key pair relationships (additive elliptic curve notation aB, ranslate to B^a
if you prefer that notation)
C = cG 
T = tG
n = tN

To recap, the goal is that the server support multiple private-public key
pairs (n,N), the client can convey the choice of N to the server, without
revealing N to third parties.

Client compute U = Hash(<cT, N>) where <,> is the pairing operation.
Client -> server:	C, U
Server: For each n compute V = Hash (<C, n>), until V=U.

Now server has determined N and continues with rest of handshake, using more
conventional crypto.

Of course, trusted authority can also determine N, so as usual distributed
across several entities.

Another downside would be the large overhead for the server who supports
many N.  Even one N might dominate the cost of the handshake.

Also, I'm not an expert in pairing based crypto, so I'm only really guessing
the IBE has the desired anonymity properties.  (That's why I applied the
hash.)

To my non-expert eye, it seems the client chooses an N that the server does
not support, this is not leaked to the server.  Also, the server does not
reveal the set of N that it supports to the client, just the N that the
client wants.

I suppose that U could also be encrypted with an unauthenticated agreed key,
if it is set after the client receives the server ephemeral public key.

Just a thought,

Best regards,

Dan

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, May 15, 2014 6:15 AM
> To: [email-masked]
> Subject: Re: [TLS] In support of encrypting SNI
> 
> -----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/Ywe22
> uE
> uGo/lKLip7obsmLCSECdldMuqPvA+Fa4r1lAed3Qx6ApwCUnqoZVxwPc1FoxfNwj
> 7A8hiw6bFpe5PmSzwfN9AxZch/FnkajzDEy8+Lm9hMZGnLWn2jxpRMk9Q/lW5a8
> =
> =nhuj
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls