Re: [TLS] channel id and oob

Hi Dirk,

thanks for looking at the two specifications. A few remarks below:

On 08/02/2013 12:10 PM, Dirk Balfanz wrote:
> 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.

This is an aspect the group agreed to solve via a separate extension, if 
I remember it correctly since it has wider applicability than just for 
these documents.

Recalling Ekr's presentation about TLS 1.3 from the last IETF meeting he 
mentioned that this would be one of the features of the new version. 
Whether it is useful to define an extension that can be used with TLS 
1.1/1.2 is a decision the ADs and chairs need to make.

>
>   * We don't want the proof-of-keypair-possession to be part of the
>     session state,

I am not entirely sure what you mean by "proof-of-keypair-possession to 
be part of the session state".

  for two reasons:
>       o 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.

The document does not require servers to store the received raw public key.

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

You don't have to use session resumption if you do not want.

I also consider the threat a bit unrealistic. If you assume that the end 
device is compromised then what prevents the malware from obtaining the 
private key before it gets into the hardware-protected secure element. I 
believe in your scenario you are not talking about a long-term ephemeral 
key pair but rather something that is dynamically created on the end 
device or dynamically provisioned.

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

We actually don't say anything about keeping the key in session state 
nor about session resumption. I consider those aspects implementation 
and configuration issues.

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

With the raw public key we actually do not say what identity the key 
refers to.

You are correct that there is an issue if we want to provide two layers 
of authentication within TLS and I am not sure whether that is even in 
scope of your document either since it is not discussed.

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

What we could do is the following:

a) Brainstorm whether we see the two layers of authentication as a valid 
use case. I don't think we both do but maybe someone else does.

b) We work on a specification that provides the confidentiality 
protection of information exchanged by the client. This could be useful 
in a number of cases, even work that is currently ongoing in the TLS 
working group right now.

c) We clarify the issues regarding the session state. I did not occur to 
me that this would be something to write about in the document but maybe 
it is worthwhile to have a discussion about it.

Ciao
Hannes

>
> Dirk.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>