Subject: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt

From: Badra <[email-masked]>
Date: Wed, 16 Nov 2011 12:25:18 +0400

Dear TLS WG members,

It's been a couple of years since "Client TLS Identity Protection" was
discussed on the TLS mailing list.

On Dec 21, 2009, the IESG approved the publication of draft
draft-hajjeh-tls-identity-protection-09.txt as an Experimental RFC.

We proved by a working implementation that the difficulties and side
effects on a TLS implementation caused by implementing the draft are not so
serious as has been feared by the reviewers and the IESG, and that the
complexity of an implementation is clearly limited and manageable.

If you support reconsidering that draft with IANA registration for
ciphersuite code points in the "specification required" range (before
asking for its sign-off in the IESG), kindly please say so on the mailing
list, like that I will inform the RFC-Ed to postpone its publication.

Best regards,
Badra

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Nov 2011 10:34:27 -0500

> discussed on the TLS mailing list.

My colleague, Wan-Teh, will be presenting something very similar at
IETF 82 this week

http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00

Cheers

AGL

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 Nov 2011 17:36:01 +0100

> http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00

I like that approach, but I don't like that only client certificates
are hidden. Whether client and server are actually distinct is
application specific, and hiding only one side might not always make
sense. Why not move both certificate messages (client and server)
after the changecipherspec? That way TLS will operate as IPSec and
offer anonymity against passive eavesdroppers.

regards,
Nikos

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 16 Nov 2011 12:13:07 -0500

> offer anonymity against passive eavesdroppers.

I like this idea.  Though for RSA key exchange we'd have to utilize
the ServerKeyExchange message which is currently forbidden.

Additionally, making the server certificate message optional would
eliminate the need for server operators to create self-signed
certificates.

Mike

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2011 12:25:16 -0500 (EST)

> eliminate the need for server operators to create self-signed

and makes it easier to plugin to DANE. See also

http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 that aims at
supressing the TLS server from sending PKIX information when the client
tells it such information is not required.

Paul

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Nov 2011 12:26:42 -0500

> offer anonymity against passive eavesdroppers.

The reason that we're concentrating only on the client certificates is
that for most situations, the server is well known and, indeed, the
client names it in an SNI extension. The clients however, have some
privacy to preserve.

But I'd support hiding the server certificate too. In general,
anything that can be encrypted should be encrypted.

Although we would like it to be a separate mechanism because we want
to get and verify the server's certificate as soon as possible in
order to minimise the number of round trips. (Note that we're sending
application data sooner:
http://technotes.googlecode.com/git/falsestart.html)

Cheers

AGL

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 18:28:14 +0100 (MET)

Michael D'Errico wrote:
> 
> Nikos Mavrogiannopoulos wrote:
> > Adam Langley <[email-masked]> wrote:
> > >

I fail to understand how moving the ServerCertificate into the
encrypted part of the handshake could work for plain RSA ciphersuites.

While I do think the proposed solution for client certs is OK,
I do not see how to make it work for the server.

The original PK(IX) idea is that you perform public key crypto
only with public keys that you have verified to trust, i.e.
you perform a public key operation only after having verified
the certificate that conveyed that public key, and you use
an ephemeral public key only after having verified the signature
on the ephemeral key after having verified the certificate containing
the public key for the signature of the ephemeral key.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 Nov 2011 18:35:49 +0100

> encrypted part of the handshake could work for plain RSA ciphersuites.

It cannot. If it is to be symmetric it has to be restricted to ECDHE and
DHE ciphersuites.

regards,
Nikos

---

From: Badra <[email-masked]>
Date: Wed, 16 Nov 2011 19:36:23 +0100

On Wed, Nov 16, 2011 at 6:13 PM, Michael D'Errico <[email-masked]>wrote:

>>> http://tools.ietf.org/html/**draft-agl-tls-**encryptedclientcerts-00<http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00>
>>>
>>

That idea is not new at all, and had been proposed to the mailing list
during August 2000.
People objected to that idea because it requires major change to TLS
machine state.

I also proposed three ways to provide the same service during 2006, the WG
didn't adopt my draft because it introduces some chages to TLS (some of
them support the same idea today ;-)) and because TLS provides
renegotiation.

@Nikos, how will you be able to provide server identity protection without
renegotiation and DH in the first Handshake?

Best regards
Badra

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Nov 2011 10:38:23 -0800

> client names it in an SNI extension. The clients however, have some

I think it's important to be clear on the level of privacy protections that
you are attempting to deliver. At an abstract level, the best you can do
is to provide anonymity of one side against active attackers. I.e., one
side needs to declare their identity first, so the attacker can always
force that side to identify. You can clearly deliver anonymity against
passive attackers for both identities.

With that said, both of these mechanisms provide less good
protection against active attack: the server exposes their identity
first, but because the existing TLS client authentication modes
involve having the client reveal his identity in the clear, the active
attacker can just pretend to be a server which does not support
encrypted client certificates, thus getting the client's identity. In
order to defend against this, the client needs to refuse to use the
original TLS client auth modes. (This isn't something new I'm
observing... it's in the security considerations in Adam's draft.)

Absent some plausible mechanism for mitigating the active
attack threat, I'm not that enthusiastic about just suppressing
the passive threat.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 Nov 2011 19:51:44 +0100

On Wed, Nov 16, 2011 at 7:36 PM, Badra <[email-masked]> wrote:

> People objected to that idea because it requires major change to TLS machine
> state.

Privacy wasn't really a hot topic in 2000, but it's not the same
today. Even security protocols follow the market :)

> didn't adopt my draft because it introduces some chages to TLS (some of them
> support the same idea today ;-))

If you mean me, If I remember well I had comments on the approach
followed, and the handling of different TLS versions but not the idea
itself. I'm always pro-privacy :)

> and because TLS provides renegotiation.

Easy. I consider DHE and ECDHE only.

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 19:57:04 +0100 (MET)

> attack threat, I'm not that enthusiastic about just suppressing

Sounds plausible to me.

In order to protect against an active attacker being able to force
disclosure of the client cert, I assume one would need a confirmation
authenticated by the server "credential" that the server supports
this extension.  An EKU in the server certificate would be conceivable,
although I feel quite uncomfortable with hardwiring an new optional
TLS protocol feature into a TLS server certificate, resulting in potentially
hard to diagnose handshake failures.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Nov 2011 11:07:34 -0800

> hard to diagnose handshake failures.

Indeed.

In the specific case of OBC, one might imagine decorating the OBC
request extension with a "only send over encrypted channel" indicator,
which gets tagged to the cert at generation time.

I know that this sounds like it's subject to active attack, but here's my
argument for why not. There are two cases:

1. The client does not have an OBC for this origin.
2. The client does have an OBC for this origin.

In case 1, in the non-attack scenario, the server advertises {OBC,
encrypted-only}.
The client generates the OBC and sends it encrypted, and stores it with the
encrypted-only flag. In the attack scenario, the server advertises
{OBC, encrypted-only}
but the attacker changes it to {OBC, plain}. The client completes the handshake
and sends the OBC in the clear, but it's a fresh OBC so (almost) no
information is leaked,
other than the non-presence of an OBC, which is apparent from traffic analysis
in any case. The handshake then fails (because of the Finished MAC)
and the client
should delete the OBC at this point.

In case 2, the client already has stored the OBC, so even if the attacker
tampers with the handshake to remove the encrypted client auth extension,
the client won't send the cert in the clear, so the attack fails.

I know it's kind of a special case, but...
-Ekr

---

From: Francisco Corella <[email-masked]>
Date: Wed, 16 Nov 2011 11:22:00 -0800 (PST)

> That idea is not new at all, and had been proposed to the mailing list during August 2000.
> People objected to that idea because it requires major change to TLS machine state.

Yep, I did propose it in the year 2000 :-)

Francisco

>________________________________
>From: Badra <[email-masked]>
>To: [email-masked]
>Sent: Wednesday, November 16, 2011 10:36 AM
>Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt
>
>
>
>
>
>On Wed, Nov 16, 2011 at 6:13 PM, Michael D'Errico <[email-masked]> wrote:
>
>That idea is not new at all, and had been proposed to the mailing list during August 2000.
>People objected to that idea because it requires major change to TLS machine state.
>
>
>I also proposed three ways to provide the same service during 2006, the WG didn't adopt my draft because it introduces some chages to TLS (some of them support the same idea today ;-)) and because TLS provides renegotiation.
>
>
>@Nikos, how will you be able to provide server identity protection without renegotiation and DH in the first Handshake?
>
>
>Best regards
>Badra 
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 20:30:31 +0100 (MET)

> offer anonymity against passive eavesdroppers.

But think of what it would mean for your server!

Typical TLS servers listen on a network socket and will engage
in a TLS handshake with an arbitrary client (either directly
or after a STARTTLS protocol upgrade).  If such a client
starts a plain TLSv1.0 handshake, the server will have only
two choices:  send his server certificate or abort the handshake.

There is no need for the "attacker" to perform an active attack (MitM)
on some other connection.  Only being able to connect to the
same server independently.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Nov 2011 13:48:40 -0600

> same server independently.

It's obviously a much smaller capability than full MitM, but that counts 
as an "active attack" in my (unofficial) nomenclature.

There do appear to be lots of cases where pure passive eavesdropping 
happens and an active attack would not. (Though not as many as some 
people hope!)

For example, consider the Google street view car Wifi sniffing incident. 
Regardless of their intent, they ended up capturing some amount of extra 
packet data. There are now government investigations  and a big public 
debate about the extent to which that data is personally identifying.

Like EKR, I'm not so interested in defenses that are defeated by a 
simple active probe. But there are still probably plenty of times it 
would come in handy.

But that also has to be weighed against the risk of promoting a false 
sense of security. Something called "Transport Layer Security Client 
Identity Protection" should be expected to strongly resist all the 
standard attacks.

- Marsh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 Nov 2011 20:51:22 +0100

> two choices:  send his server certificate or abort the handshake.

Why is that dilema?

> same server independently.

HTTP servers don't really gain from this protection, but consider a chat
client connecting to another using TLS. It doesn't matter which one is
the server or the client. Both need their certificates hidden.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Nov 2011 14:02:37 -0600

> the server or the client. Both need their certificates hidden.

You can't protect both identities from active attack.  You can protect
one from passive attacks and the other from active (and passive)
attacks.  If both identities require equal protection, then what?  All
identities have equal privacy requirements, but some have more equal
privacy needs.  For peer-to-peer networking you'll just have to allow
one identity to be less protected than the other, but since anyone can
ask for that node's identity, you've got no real protection for it at
all.  Peers in p2p might use oob methods for exchanging pseudonymous
PSK credentials, or they might use DHE or ephemeral self-signed certs
and then confirm the connection in an oob way (not unlike OTR).

I think it's best to leave the p2p case out of scope, or to at most
specify what material p2p users would have to confirm is the same for
a given connection in an oob way.  There probably is real value in
protecting client identities (and if we client/server role reversal
were common, then real value in protecting one of the two identities),
but much less in protecting both.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Nov 2011 01:22:18 +0200

> the server or the client. Both need their certificates hidden.

That's what PSK will get you. PSKs are harder to provision, but both sides need to know the PSK for the handshake to succeed.

With public keys in certificates, no matter how you design the protocol, one side is going to disclose their identity first. In TLS that is not the server. In IKE, it's the initiator.

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Nov 2011 00:42:44 +0100 (MET)

> > two choices:  send his server certificate or abort the handshake.

That is a principal characteristic of Public Key technology
whenever it is used in combination with signed associations
of identity, such as X.509 certs.

It does not happen if there is the requirement that keys must
be pre-shared and each peer must know in advance who it is talking to.
As soon as the peer whose key is used first reveals an identifier
for its key, its identity will be recoverable for everyone who
also has that (public) key pre-shared or some means to obtain
the key.

> the server or the client. Both need their certificates hidden.

I believe that is to be impossible whenever the key that gets used
first is identified/distinguished somehow instead of pre-known to
the peer and implied.

Even when doing anon-DH first and then mutual authentication, any
interested party can try the same with the server, succeed the anon-DH
handshake and learn the TLS servers certificate, even though that
certificate no longer travels over the wire in plaintext.  That is
an authentication bootstrapping problem.  It will not go away,
no matter how much code and protocol overhead you throw at it.

-Martin

---

From: SM <[email-masked]>
Date: Thu, 24 Nov 2011 08:10:56 -0800

Hi Badra,
At 00:25 16-11-2011, Badra wrote:
>ciphersuite code points in the "specification required" range 
>(before asking for its sign-off in the IESG), kindly please say so 
>on the mailing list, like that I will inform the RFC-Ed to postpone 
>its publication.

The draft is being published through the Independent Stream 
(non-IETF).  According to the Copyright Notice, the document may not 
be modified outside the IETF Standards Process.

Regards,
-sm