Subject: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"

From: Dirk Balfanz <[email-masked]>
Date: Thu, 8 Nov 2012 13:22:33 -0800

Hello everybody,

As you might have noticed, I have let the TLS-Origin-Bound Certificates
(TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
expire. The reason for this is that we (i.e., Google) had implemented
TLS-OBC as described in the draft (in Chrome and server-side), and we
weren't too happy with it. There were a few of problems:

(1) Client certificates are part of the session state. Not only does that
mean that the session state is now considerably bigger than it used to be,
it also means that anyone that can steal session secrets (malware on the
client) can make it look to the server as if they were in possession of the
client's private key, even if that private key sits in a TPM on the client.

(2) The logic in the client and server that treated OBCs and normal client
certs differently, even though they were delivered through the same kind of
Certificate message, turned out to be a little more complex that we wanted
it to be.

(3) To keep the public key of the client (which acts like a machine
identifier) away from prying eyes, we had to entangle the TLS-OBC extension
with another extension that reordered handshake messages (and sent the
Certificate message after the ChangeCipherSpec message). That added further
ugly complexity.

(4) The main use case for this was to be able to "channel-bind" cookies.
Cookies, however, can be set across more than just a web origin. When the
underlying transport uses different client keys for different origins
inside the same TLD, then we can't bind a domain cookie to the underlying
TLS channel.

(If you were at IETF 85 you might have seen Adam give a short talk about
this.)

To fix all this, we wrote a new proposed spec:
http://tools.ietf.org/html/draft-balfanz-tls-channelid-00

This spec is silent on the scope of the keys (but in practice we expect
browsers to use eTLD+1 now instead of more fine-grained origins), and
addresses all the other issues explicitly: the Channel IDs are not part of
the TLS session state, and are exchanged after encryption is turned on.

A comment on the new name: One of the ways the new spec is simpler than the
old one is that there are no more X.509 certs involved in proving
possession of the client key - so there goes the "C(ert)" in the "OBC"
acronym. Because of the agnosticism of the new spec toward the scope of the
client keys, there is also no "O(rigin)" anymore. Hence, we needed a new
name.

You can play with this proposed mechanism by getting Chrome 24 (just
released to the beta channel), and observing its connections to Google web
properties.

Thoughts?

Cheers,

Dirk.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 08 Nov 2012 23:04:33 +0100

> Hello everybody,

Hello,
 Some comments/questions inline.

> client's private key, even if that private key sits in a TPM on the client.

How is that? Do you mean by session resumption? Isn't it the same on the
current draft?

> client keys, there is also no "O(rigin)" anymore. Hence, we needed a new

The approach actually looks like a prime user of the
draft-ietf-tls-oob-pubkey extension that allows to send the
SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
allows any type of client public key, instead of sticking to a fixed
ECDSA curve? No additional extension would be required.

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Thu, 8 Nov 2012 17:45:48 -0500

On Nov 8, 2012 5:04 PM, "Nikos Mavrogiannopoulos" <[email-masked]> wrote:
> current draft

ChannelIDs are not part of the session state and need to be sent in an
abbreviated handshake. (The draft may be unclear on that point.)

> ECDSA curve? No additional extension would be required.

That was suggested in the meeting. The reasons why that wouldn't work
without modification are that: it's part of the session state, it's
unencrypted in the handshake and we cannot also have a client cert if we do
that.

One of our reasons for doing something else rather than modifying client
certs was our experience that doing so turned into a bit of a mess when we
did it last time.

Cheers

AGL

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 9 Nov 2012 10:55:47 +0100

> unencrypted in the handshake and we cannot also have a client cert if we do

Hello,
 The part of the session state I think would be hard to overcome.
Everything used in a TLS handshake is part of the state. What do you
actually need there is that this key and signature need to be resent
even if the client is resuming a session?

The unencrypted in the handshake is an early design choice in TLS. I
think TLS should be updated to cope with that, rather than each
individual extension try to patch that issue. Having said that there
was Marsh's proposal but I don't know if it is still active. In any
case this could be combined with a generic mechanism to have data in
TLS send after encryption is enabled (so that other extensions that do
that wouldn't reinvent the wheel).

About having a client certificate wouldn't it be more useful if a
client could submit more than one certificates/public keys? I haven't
seen much protocols doing that, but that is what your approach is
actually doing.

> certs was our experience that doing so turned into a bit of a mess when we

Was it due to client constraints or because of the required changes?

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Fri, 9 Nov 2012 09:46:50 -0500

> even if the client is resuming a session?

Yes. Since the aim is to eliminate barer tokens as a means of
authentication it's unfortunately, for our purposes, that session
resumption makes a barer token out of the key pair!

> that wouldn't reinvent the wheel).

We do use the EncryptedExtensions mechanism which was suggested by
someone on this list (sorry, I forget who) for NPN. (And it part of
the NPN spec now.) So it does use a generic mechanism for sending
encrypted handshake data, but it doesn't solve the generic problem of
encrypting client-certificates any longer.

> Was it due to client constraints or because of the required changes?

It was because our use turns out to be substantially different from
client-side certificates that the code to support both in a single
mechanism turned into a lot of ugly exceptions.

Cheers

AGL

---

From: Chris Richardson <[email-masked]>
Date: Fri, 9 Nov 2012 15:30:32 -0500

Perhaps I'm being picky, section 4 requires an illegal_parameter alert
if the cipher suite is insufficiently strong.  Doesn't
handshake_failure make more sense here?

On Thu, Nov 8, 2012 at 4:22 PM, Dirk Balfanz <[email-masked]> wrote:
> underlying transport uses different client keys for different origins inside
> the same TLD, then we can't bind a domain cookie to the underlying TLS
> channel.
>
> old one is that there are no more X.509 certs involved in proving possession
> of the client key - so there goes the "C(ert)" in the "OBC" acronym. Because
> of the agnosticism of the new spec toward the scope of the client keys,
> there is also no "O(rigin)" anymore. Hence, we needed a new name.
>

---

From: Adam Langley <[email-masked]>
Date: Fri, 9 Nov 2012 16:51:56 -0500

> handshake_failure make more sense here?

Does it? From RFC 5246:

illegal_parameter
      A field in the handshake was out of range or inconsistent with
      other fields.  This message is always fatal.

Seems to make sense, no?

Cheers

AGL

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 10 Nov 2012 11:21:27 +0100

> resumption makes a barer token out of the key pair!

You cannot really avoid that since this is the purpose of the session
resumption. Authentication only occurs in full sessions, so by modifying
resumption and requiring a signature you convert it to some kind of
resumption with some authentication. Don't the time limitations of
resuming sessions compensate for your concerns? (which I suppose is
preventing someone to authenticate by stealing session data).

>>> unencrypted in the handshake and we cannot also have a client cert if we do

Thinking it again, the draft is pretty much about using pseudonyms
(public keys) to authenticate to servers over TLS. Authenticating with
both the pseudonym and the named certificate doesn't look like the main
use-case but a server may want to associate them and that could follow a
mechanism similar to what you propose.

> mechanism turned into a lot of ugly exceptions.

What if the server indicates early whether he'd like an authentication
with a pseudonym or a named certificate (or both for association)?
Wouldn't that simplify the handling of the client provided certificate?

regards,
Nikos

---

From: Chris Richardson <[email-masked]>
Date: Sat, 10 Nov 2012 14:27:00 -0500

If I was looking at a packet capture and wanted to figure out what
exactly went wrong and how to make the connection succeed,
illegal_parameter would lead me to incorrect conclusions.
handshake_failure ("unable to negotiate an acceptable set of security
parameters") would lead me in the right direction.
insufficient_security would be ideal, but it is only supposed to be
sent from server to client.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 11 Nov 2012 17:30:34 -0800

Is is possible for you to do a separate Internet-Draft on EncryptedExtensions, and then point to it from draft-balfanz-tls-channelid? I ask because there are probably other future extensions that will want to use that extension, and if the RFC level of ChannelID doesn't permit it, we'll be in a similar situation as we are for RFC 6091.

FWIW, I think ChannelID is a fine idea and should be adopted here, but I'm not convinced it will be put on Standards Track.

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Mon, 12 Nov 2012 13:09:00 +0000

On 9 November 2012 14:46, Adam Langley <[email-masked]> wrote:
> Yes. Since the aim is to eliminate barer tokens

"bearer" :-)

> as a means of

---

From: Ben Laurie <[email-masked]>
Date: Mon, 12 Nov 2012 13:24:23 +0000

> the TLS session state, and are exchanged after encryption is turned on.

a) How can this be usable unless it is specified what browsers do?

b) eTLD+1 ... how will you deal with, e.g, uk, which has just proposed
removing a level from the TLDs? Hasn't this kind of mechanism already
been shown to be impossible to maintain (cookies are supposed to be
banned from eTLDs but in practice aren't always, IIRC)?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 12 Nov 2012 10:06:49 -0500

> banned from eTLDs but in practice aren't always, IIRC)?

fwiw, this actually is currently "maintained" by tracking a ton of
special cases; the usual place this work is coordinated publicly is at
http://publicsuffix.org/

It's not a particularly pretty solution, but people do use it.  I can't
tell if it's the intent to reuse this same list for channelID or not,
though.

	--dkg

---

From: Adam Langley <[email-masked]>
Date: Mon, 12 Nov 2012 11:20:04 -0500

On Sat, Nov 10, 2012 at 5:21 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> Don't the time limitations of

Time limits would be better than no time limits, but any time limit
short enough to be acceptable in this case would make session
resumption completely ineffective.

> Wouldn't that simplify the handling of the client provided certificate?

All the special case handling basically made a mess of the code. I
don't think any small changes would have changed that. (This is not a
precise argument, and it may not apply in all code bases. I am
orientated towards OpenSSL and NSS for obvious reasons.)

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Mon, 12 Nov 2012 11:21:09 -0500

> FWIW, I think ChannelID is a fine idea and should be adopted here, but I'm not convinced it will be put on Standards Track.

EncryptedExtensions is also used in the NPN. I'd be happy to split it
off if the WG were to adopt something that required it.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Mon, 12 Nov 2012 11:23:28 -0500

> a) How can this be usable unless it is specified what browsers do?

It seemed that the higher-level behaviour wasn't in-scope for a
document about TLS protocol changes. Although I agree that it should
be documented, I think it's a different document.

(Higher level behaviour pulls in messy hacks like the Public Suffix
List, as you note in (b))

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Tue, 20 Nov 2012 22:09:45 +0100 (CET)

Chris Richardson wrote:
>
> Adam Langley <[email-masked]> wrote:
>>
>> Chris Richardson <[email-masked]> wrote:
>>>
 
Are you refering to this (*) text:

  http://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-4

   A new handshake message type ("encrypted_extensions(TBD)") is
   defined.  If the server included a "channel_id" extension in its
   "ServerHello" message, the client MUST verify that the selected
*  cipher suite is sufficiently strong.  If the cipher suite provides <
*  80-bits of security, the client MUST abort the handshake with a fatal
*  "illegal_parameter" alert.  Otherwise, the client MUST send an
   "EncryptedExtensions" message after its "ChangeCipherSpec" and before
   its "Finished" message.

rfc5246 defines for the alert "insufficient security" like this.

  http://tools.ietf.org/html/rfc5246#page-33

   insufficient_security
      Returned instead of handshake_failure when a negotiation has
      failed specifically because the server requires ciphers more
      secure than those supported by the client.  This message is always
      fatal.

The second sentence "This message is always fatal" should to be interpreted
as a requirement.  The first sentence describes the purpose for which
rfc5246 uses this alert, it can not be interpreted to limit its usage
for server->client signaling.

However, in a TLS handshake, the client *MUST* include the list of
cipher suites acceptable to the client in ClientHello.  If a cipher
suite is not acceptable to the client, it should not appear in the
ClientHello in the first place.  If it appears, it MUST be acceptable
to the client if the server chooses it.

The suggexted "illegal_parameter" is probably meant for the situation
where the server chooses a cipher suite that the client never offered
(which _might_ be the result of an Man-in-the-Middle attacker).

To me, it is difficult to conceive a usage scenario where the alert
"insufficient_security" would be the appropriate response, rather than
an indication that the client is goofing the list of acceptable
cipher suites in ClientHello.

A client that did _not_ offer AES256_CBC-SHA1 (due to configuration)
should also abort with an illegal_parameter alert if the server chooses
that cipher suite, even though I'm not aware of any security concerns
about that cipher suite (pre-TLS1.1 IVs is a different issue).

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 21 Nov 2012 00:27:31 +0100

> cipher suites in ClientHello.

There is a use-case for this alert (although not in its description).
Think of a server that uses a 256-bit DH key. In that case,
unfortunately, the client cannot do much except close the connection
with an alert.

regards,
Nikos

---

From: [email-masked] (Martin Rex)
Date: Wed, 21 Nov 2012 02:26:31 +0100 (CET)

Nikos Mavrogiannopoulos wrote:
> Martin Rex wrote:

Thanks!  

Yes, that looks like a perfectly valid client-side use case for the
"insufficient_security" alert.

-Martin