[TLS] channel id and oob

[Dirk Balfanz <[e-mail]>]

Hi guys,

I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and
whether it can be applied to the use cases we have in mind for Channel ID.

My conclusion is that it can not, or that the necessary modifications to
the OOB draft would be too substantial to be considered during Last Call.

First, the similarities: both proposals allow the client to prove
possession of a key pair. The fact that this proof-of-possession is
forthcoming is negotiated using the TLS extension mechanism (during
ClientHello/ServerHello).

Now for the differences:

   - We don't want the client public key to be sent in the clear. It's a
   client identifier, and shouldn't be known to anyone but the client and the
   server.

   - We don't want the proof-of-keypair-possession to be part of the
   session state, for two reasons:
      - It blows up the session state, with ramifications on the size of
      the fleet of servers that cache this information. Remember that
in our use
      case, we don't intend this to be used for the occasional client
that wants
      to use non-password authentication with the server; it's designed to be
      used by _every_ client talking to big service providers like Google. Raw
      public keys are of course smaller than full certificates, but they still
      represent a significant increase in the size of session state.
      - We don't want someone who is not actually wielding the private key
      of the keypair to make it appear to the server as if they were in control
      of that private key. Session resumption, however, gives you that power:
      Let's assume that the private key of the keypair sits in a
      hardware-protected secure element, and is therefore out of reach of
      malware. Master secrets and other session information, however, is very
      likely kept in RAM and therefore available to thieves. If such a thief
      extracts the session data from the client and resumes the session, the
      server will treat the thief as the holder of the original private key. If
      the proof-of-keypair possession is explicitly declared not part of the
      session, then a client has to re-prove possession of the keypair even
      during abbreviated handshakes. Thus, a thief of session secrets
(but not of
      the private key) won't be able to convince a server that it is in control
      of that private key.

The oob-draft keeps the raw key in the session state, thus inheriting this
problem with session state and session resumption.


   - Channel ID keys are different from key material sent in the
   Certificate message, and the certificate message shouldn't be overloaded
   with this new semantics: Key material presented in the Certificate
   message (even if it's a raw key) presumably carries some semantics for the
   application: "this is a certain user", "this is an enterprise-issued
   machine", etc., while the Channel-ID keys are always self-generated and
   their semantics include (among other things) "this is the key that will be
   nuked when the user presses the 'reset my browsing state' button". It makes
   for tricky implementations when those two different semantics get mapped to
   the same protocol message. More importantly, applications may want to do
   both: authenticate a user with a client cert, and then set a channel-bound
   cookie as a result of the authentication. You can't do that if you only
   have one proof-of-possession available in the handshake.

As mentioned above, I don't really see how this issues could possibly be
addressed within the draft-ietf-tls-oob-pubkey draft, especially since it's
in last-call. Just the first point above alone seemed to be something that
folks didn't want to touch until TLS 1.3.

Thoughts?

Dirk.