Subject: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS

From: "Viktor S. Wold Eide" <[email-masked]>
Date: Mon, 24 Aug 2015 22:56:53 +0200

Hi,

I am looking for a way to achieve identity hiding for DTLS 1.2, which also
hopefully can be used in (D)TLS 1.3, when available.

>From what I understand, for (D)TLS 1.2 it would be possible to perform an
anonymous unencrypted handshake and then to renegotiate the connection with
authentication within the encrypted channel, e.g., according to the expired
draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation
will be removed in the upcoming 1.3 version.

What is likely to be the recommended way to achieve identity hiding for
(D)TLS 1.3, if any?

[1] Transport Layer Security (TLS) Encrypted Handshake Extension,
draft-ray-tls-encrypted-handshake-00, expired in 2012
[2] The Transport Layer Security (TLS) Protocol Version 1.3,
draft-ietf-tls-tls13-07

Best regards
Viktor S. Wold Eide

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Aug 2015 14:17:20 -0700

> [2] The Transport Layer Security (TLS) Protocol Version 1.3,
TLS 1.3 encrypts both the client's and server's certificates already.
The server's certificate is secure only against passive attack. The
client's is encrypted with a key that the client can authenticate as
belonging to the server.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Aug 2015 17:33:18 -0400 (EDT)

On Mon, 24 Aug 2015, Eric Rescorla wrote:

> The server's certificate is secure only against passive attack.

Not having read the TLS 1.3 draft, in IKE parties can send a hash of the
CAs they trust, so unless you receive a hash of a known CA to you, you
can withold your own certificate from being sent.

Is a similar mechanism not planned for TLS 1.3?

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Aug 2015 14:39:40 -0700

> Is a similar mechanism not planned for TLS 1.3?

Well, TLS already permits the server to indicate the DN of CAs which should
be in the path. I have not heard of any plan to add a digest indication.

-Ekr

---

From: Badra <[email-masked]>
Date: Tue, 25 Aug 2015 02:19:09 +0400

Hi,

Another solution was approved for publication as experimental by IESG in
2009 but I declined to process with Pasi Eronen way (previous WG co-Chair)
of publishing the document.

It is available at
https://tools.ietf.org/html/draft-hajjeh-tls-identity-protection-09 and it
works for TLS and DTLS

Best regards, Mohamad

On Tue, Aug 25, 2015 at 12:56 AM, Viktor S. Wold Eide <
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 01:19:14 +0000

> Is a similar mechanism not planned for TLS 1.3?

This would break DANE, unless the mechanism also allowed the client
to send a TLSA RRset instead, with the server then needing code to
figure out which chains match which TLSA RRs.  This is I think too
complex.  

If the client is willing to live without any certificate at all,
it can include anon-(EC)DH ciphersuites in its cipherlist at a
higher preference than any ciphersuites that use certificates..
Otherwise, the server sends a suitable chain per SNI and
closest match to supported signature algorithms.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Aug 2015 21:56:50 -0400 (EDT)

> figure out which chains match which TLSA RRs.  This is I think too

If you publish your public key in DNS you would also just always
send your public key over TLS. There is no privacy issue there,
so no reason to withhold it.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Aug 2015 02:19:26 +0000

> so no reason to withhold it.

Not sure how this comports with your original proposal.  What would
a client have to send to convince the server to not withold its
certificate?  What does witholding it mean anyway, the client needs
the public key at least if the server signs the key exchange.  Is
there something here worth pursuing in the context of TLS?

-- 
	Viktor.

---

From: Pascal Urien <[email-masked]>
Date: Tue, 25 Aug 2015 10:43:19 +0200

Hi

a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt
the client certificat with an extra key computed from the master
secret

see
https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01

Rgs

Pascal

---

From: "Viktor S. Wold Eide" <[email-masked]>
Date: Thu, 27 Aug 2015 10:37:01 +0200

On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla <[email-masked]> wrote:

>> I am looking for a way to achieve identity hiding for DTLS 1.2, which
>> also hopefully can be used in (D)TLS 1.3, when available.
>>
Thanks a lot for the clarification.

Would it be reasonable to include your answer or something similar into the
TLS 1.3 draft, for example in the "Major Differences from TLS 1.2" section?

Best regards
Viktor S. Wold Eide

---

From: "Viktor S. Wold Eide" <[email-masked]>
Date: Thu, 27 Aug 2015 10:40:05 +0200

On Tue, Aug 25, 2015 at 12:19 AM, Badra <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-hajjeh-tls-identity-protection-09 and
> it works for TLS and DTLS
>
>
Thanks for the reference.

Best regards
Viktor S. Wold Eide

---

From: "Viktor S. Wold Eide" <[email-masked]>
Date: Thu, 27 Aug 2015 10:42:44 +0200

> https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01
Thanks for the suggestion and for the reference.

Best regards
Viktor S. Wold Eide

---

From: "Viktor S. Wold Eide" <[email-masked]>
Date: Thu, 27 Aug 2015 11:14:01 +0200

> client's is encrypted with a key that the client can authenticate as

It's good to see that both the client's and the server's certificates are
encrypted in TLS 1.3, providing protection against passive eavesdropping.

For some use cases it might be worthwhile to reduce the information made
available to an active attacker also. Are there any suggestions in this
direction for TLS 1.3?

One might think of a multi stage approach, something like:
- Anonymous connection establishment, resulting in a secure channel.
- Authentication by means of group certificate.
- Authentication by means of a host specific certificate.

The purpose of the second step above is to first only provide the group
identity to an active attacker, and then to reveal the host identities
(certificate information) only after group membership has been mutually
authenticated.

Does something like this seem reasonable for TLS 1.3 or are there any other
ways for providing protection of identities against an active attack?

Best regards
Viktor S. Wold Eide

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2015 04:17:08 -0700

On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide <
[email-masked]> wrote:

>>> From what I understand, for (D)TLS 1.2 it would be possible to perform
>>> an anonymous unencrypted handshake and then to renegotiate the connection
>>> with authentication within the encrypted channel, e.g., according to the
>>> expired draft [1]. From the latest TLS 1.3 draft [2] it appears that
>>> renegotiation will be removed in the upcoming 1.3 version.
>>>
> Would it be reasonable to include your answer or something similar into
> the TLS 1.3 draft, for example in the "Major Differences from TLS 1.2"
> section?
>

Sure. It's mostly a changelog now, but I'll try to add something.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2015 04:18:08 -0700

On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide <
[email-masked]> wrote:

> authenticated

I don't think this matches most TLS use cases very well, since the client
generally isn't authenticated at all, so there's no point in the server
progressively
revealing more.

-Ekr

---

From: "Viktor S. Wold Eide" <[email-masked]>
Date: Fri, 28 Aug 2015 16:27:28 +0200

> generally isn't authenticated at all, so there's no point in the server
Although the client generally is not authenticated currently, TLS 1.3 and
DTLS 1.3 are likely to stay for a long time and then to be used for lots of
different use cases, including more peer-to-peer interaction. For some
use-cases, including peer-to-peer interaction, being able to progressively
reveal more information would improve protection. Whether this is a
worthwhile tradeoff or not, depends on many different factors. I think it
is both relevant and interesting to see to what extent (D)TLS 1.3 would
support such use cases.

Best regards
Viktor S. Wold Eide

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Aug 2015 14:49:33 +0000

> is both relevant and interesting to see to what extent (D)TLS 1.3 would

It seems that with TLS 1.3 the client MUST send SNI, presumably in
the clear.  Typically there's not much else of interest in the
server certificate to hide.  I don't see a realistic way to hide
the server identity even from passive wiretap via TLS.

Encryption of the TCP layer, plus TLS channel-binding (or
super-encryption) might be necessary to limit the metadata leakage
to just the transport layer endpoint addresses.  With IPsec the
leakage is just the network layer addresses.

Is anyone looking into leveraging TCPinc (when available) in TLS?
Extract channel-binding data from the socket, authenticate it with
TLS, and perhaps use TLS with NULL ciphers and if possible a
simplified handshake...

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 28 Aug 2015 12:13:03 -0400

On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote:
> Having discussions through github is a really bad idea.

You're right. I posted a stupidly long side-note in there. I intended to bring it to the list too, which I'll do now.

> the server identity even from passive wiretap via TLS.

Currently, we're at implementations MUST support (not necessarily send) SNI, servers MAY require it, and servers SHOULD error on such a failed requirement. This doesn't change the status quo much. If servers don't require it, you don't need to send it. HTTP/2 has its own SNI requirement, though, so lots of TLS will be moving in that direction.

The idea I had the other day is that we can technically do SNI encryption with the current TLS 1.3 draft, as-is. All that needs to really be done is stick it in a 0-RTT EncryptedExtensions, preferably only when the server specifies that it is allowed via adding a flag to server config. This would require the actual server share the 0-RTT DH key across the virtual servers it's picking via SNI, so early data probably should be off in this instance for many use-cases.

The simplest route that would allow for encrypted SNI with 0-RTT application data allowed would be to just add a second long-term DH key to the server config for SNI (and an option for servers to have one do both if they don't need two). Seeing as this would still need to be opt-in via a flag in the config, we could use the same extension ID and just encrypt it using the second key. Servers that provide an SNI key get encrypted; others get clear or none.

If we can also get a way to distribute server config out-of-band, this would even allow initial-connection SNI encryption.

I don't think encrypted SNI to servers without any prior information is really that viable, and that's been said before by others on this list. Now, with that said, you could just create a way for any client to ask a server for its config without any attempt to connect right away, in which case it can follow up with encrypted SNI at the cost of that 1-RTT (e.g. the QUIC way of doing things). Even if we allow ServerConfiguration to be optional normally, we could add this config request mode and make support for that mandatory (though, potentially with short-lived keys). This route would still require some prior information about this server: knowledge that it could request a key for SNI at all without just getting rejected. Doing so without that would require a multiple attempt check of some kind that's probably a bad idea.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Aug 2015 16:22:52 +0000

On Fri, Aug 28, 2015 at 12:13:03PM -0400, Dave Garrett wrote:

> The idea I had the other day is that we can technically do SNI encryption
> with the current TLS 1.3 draft, as-is. All that needs to really be done
> is stick it in a 0-RTT EncryptedExtensions, preferably only when the server
> specifies that it is allowed via adding a flag to server config. This
> would require the actual server share the 0-RTT DH key across the virtual
> servers it's picking via SNI, so early data probably should be off in this
> instance for many use-cases.

So the client would now need to cache some session data by transport
address, and other data by name and port.  That's rather complex.
And how often will the same client visit multiple servers at the
same transport address?

I don't really see this as viable or worth the effort.

> I don't think encrypted SNI to servers without any prior information is
> really that viable, and that's been said before by others on this list.

I don't think SNI hiding is viable without encryption at the
transport or network layers.  And there's still a metadata leak
via DNS which may prove difficult to address.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Aug 2015 16:33:31 +0000

> > The idea I had the other day is that we can technically do SNI
> > encryption with the current TLS 1.3 draft, as-is.

Yeah, some of us talked about this in Dallas, etc., when the "semi-static EDH key" really started to take hold.  I showed slides at the interim before IETF 90 in Toronto, that seemed to convince everyone that it doesn't really get you the privacy you think you get.  (I couldn't find them in the meeting materials; if anyone wants the PDF let me know.) There's still the DNS leakage, to which dkg reasonably points out that we should not succumb to the deadly embrace of each component waiting for the other.

> And how often will the same client visit multiple servers at the same
> transport address?

Anyone who visits sites hosted by a CDN.  And, I suspect, many large portals.
 
> I don't really see this as viable or worth the effort.

Agree.

	/r$

---

From: Dave Garrett <[email-masked]>
Date: Fri, 28 Aug 2015 13:01:49 -0400

> Anyone who visits sites hosted by a CDN.  And, I suspect, many large portals.

How's it done with IPv6, generally? Are there setups where everyone is sharing a v6 IP? We could eventually get to the point where a reverse DNS lookup is all that's needed for everyone if things were set up smartly. Probably a better setup for things to work, but worse for passive surveillance. (though, IPv6 could eventually let clients randomize their IP frequently, which helps some things; getting off-topic here, though)

> > I don't really see this as viable or worth the effort.

I agree that it's a lot of effort for relatively little gain. I might be worth considering, but if the consensus is that TLS just isn't designed to do this easily enough to be worth it, then I don't really dispute a decision to just drop the concept.

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Aug 2015 17:06:01 +0000

> How's it done with IPv6, generally?

We don't see address-sharing with IPv6, although I wonder if that will change when the routing tables get too big. :)  We also don't see anyone willing to go IPv6-only; it's not close to universal enough yet.

> I agree that it's a lot of effort for relatively little gain.

It doesn't protect those who need it against those who would harm them.