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

[Adam Langley <[e-mail]>]

On Nov 8, 2012 5:04 PM, "Nikos Mavrogiannopoulos" <[e-mail]> wrote:
>
> 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

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

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

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls