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

[Nikos Mavrogiannopoulos <[e-mail]>]

On 11/08/2012 10:22 PM, Dirk Balfanz wrote:

> Hello everybody,


Hello,
 Some comments/questions inline.

> (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.


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

> 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.


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