Re: [TLS] comments on draft-balfanz-tls-channelid

[Adam Langley <[e-mail]>]

Thanks! I can answer a few of the techincal questions. I'll leave your
comments on the wording and such to Dirk.


> 2. What are the ramifications if the TLS WG does not adopt an
> EncryptedExtensions mechanism?  I.e., what are the downsides to the "channel
> id" being publicly exposed, i.e., the security ones as well as the privacy
> implications?

It would mean that clients send, in the clear, a unique identifier for
each eTLD+1. This would allow TLS connections to be deanonymised etc.

> 6. This mechanism should be compared/contrasted with TLS Channel Binding
> RFC5929. They don't appear to be mutually exclusive on first thought. What
> are the semantics if they are both employed by an application?  For what
> might one employ one or the other or both concurrently?

They are certainly related. Something like ChannelIDs could be
implemented at the application layer by signing channel binding
values. I think channel bindings were designed to provide exactly
this, but to the application.

> what are the threats if a long-term, asymmetric-key-based client identifier
> is sent in the clear during TLS handshake?  Is it mostly a privacy concern?
> Or is it because of anticipated use cases of binding app-layer info to the
> TLS layer?

I think it's primarily a privacy concern.

> ..so I'm not sure how "session resumption secrets" are "equivalent bearer
> tokens" ?

The session resumption information is sufficient to authenticate with
a given client certificate. That is, if the client certificate is in a
hardware token and signs a TLS handshake, then by stealing the session
resumption information (from either end of the connection), an
attacker steals something equivalent to the client-cert private key in
some sense.

> you mean that the "x" and "y" fields (of the ChannelIDExtension struct)
> contain the  affine coordinates of a P-256 [DSS] curve point comprising an
> ECC public key "Q" ?

Yes.

> hashes of both the client-sent and server-sent handshake messages, as seen
> by the client?

Yes.

> but presumably the same (long-lived?) TLS client identifier Q = (x,y)  used
> and only (r,s) are different ?

It's certainly expected that the client would use the same public key
(i.e. (x, y) pair), yes.

> why?  simply for privacy reasons?

Yes.

> Or is the main concern that the "channel id" will be used by app layers, eg
> in HTTP cookies, in order to bind objects to a particular TLS client-server
> pair, and thus the "channel id" should be protected as a secret?

No, the Channel ID isn't a security secret. We wouldn't want to
broadcast it for privacy reasons but, since one has to prove
possession of the private key in order to use it, just the public key
isn't sensitive.

>>    We do this by sending a
>>    constant-length Channel ID under encryption.  However, since the
>>    Channel ID may be transmitted before the server's Finished message is
>>    received, it's possible that the server isn't in possession of the
>>    certificate that it presented.
>
> do you mean in possession of the corresponding private key (to the cert it
> presented) ?

Yes.

> We assume that TLS provides sufficient security to prevent these attackers
> from being able to hijack the TLS connection.

Yes.

>>                                              However, as the signature
>>    covers the handshake hashes, and therefore the server's certificate,
>>    it wouldn't be accepted by the true server.
>
> this essentially means that a attacker server with a mis-issued certificate
> cannot act as a real-time TLS proxy between the TLS client and legit server,
> yes?
>
> But otherwise such an attacker could potentially mount an impersonation of
> the legitimate server, yes?

Yes, but the worry is that the attacker could impersonate the
/client/, not the server.

>>    Against an attacker with the legitimate server's private key we can
>>    provide the second guarantee only if the legitimate server uses a
>>    forward-secret cipher suite, otherwise the attacker can hijack the
>>    connection.
>
>
> here "connection" means the long-lived "security association" between TLS
> client and legit server, yes?

I think connection means connection in this case. The attacker could
derive the session resumption information, but I don't think that
helps them any more than simply hijacking the connection.



Cheers

AGL