Transport Layer Security (TLS) Channel IDs

[Brian Smith]

See http://tools.ietf.org/html/draft-balfanz-tls-channelid-01. I am
interested in hearing from others on whether we should implement this
or something like it in Firefox. Please read the draft carefully as
there are subtle privacy and security considerations that have been
addressed in it already.

Channel ID allows a server and a client to agree to a key pair with
TOFU-style trust. The client generates a random key pair and then
proves possession of the private key as part of the TLS handshake it
makes to that server, using the same key pair for every future
connection to that same server. The server keeps track of whether or
not each request that bears a cookie came from a TLS connection that
had such a proof of possession. If the cookie was set on a connection
with a proof of possession, but the connection that is using the
cookie in a request does not have a proof of possession of the same
keypair, then the server will take this as evidence that the cookie
has been stolen and should no longer be trusted. Presumably, the
server would then ask the user to log in with their username/password
and/or the server may require two-factor authentication for these
cases.

Note that some limitations of key pinning mean that this mechanism is
still useful even on sites with pinned keys. In particular, because of
the need for browsers to work with anti-virus software and security
gateways like Microsoft Threat Management Gateway, key pinning
implementations generally need to, by default, accept user-added root
CAs from being blocked by pinned keys, as our friends on the Chromium
team found out already. (Please start a new thread to discuss this, if
you want to discuss this.)

Our Googler friends have already implemented and shipped this
mechanism as part of Google Chrome and on Google's servers. They have
patches to NSS, the crypto library that Firefox uses, that they are
happy to share with us. Just accepting the patches is not sufficient,
because there are privacy concerns that would need to be mitigated in
other parts of Firefox.

One thing that is up for debate is what the security/privacy tradeoff
should be. In particular, the channel ID keypair itself acts like a
cryptographically strong cookie and could be used for tracking. The
Chromium team has implemented some measures to make it so that channel
ID is treated like cookies in terms of the browser's cookie management
policy. We should investigate whether we could improve the privacy
protections for this mechanism to make sure it doesn't become a
new/better way to track people. Ideally, we would know which cookies
were associated with a login event (username/password submission,
Persona/BrowserID login, etc), and then only generate and use a
Channel ID keypair in those situations. However, this would require us
to be able to classify cookies into "authentication" and "tracking"
buckets, which is something that we probably cannot do perfectly and
automatically. Because this mechanism would require changes to both
clients and servers for it to be effective, it seems reasonable that
we could require servers that want to use Channel ID to do something
special when the user logs in, if needed. And/or, we may be able to
repurpose some of the password manager login detection logic to detect
when to start using ChannelID for a server.

Thoughts?

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Gervase Markham]

On 17/09/13 03:52, Brian Smith wrote:
> One thing that is up for debate is what the security/privacy tradeoff
> should be. In particular, the channel ID keypair itself acts like a
> cryptographically strong cookie and could be used for tracking. The
> Chromium team has implemented some measures to make it so that channel
> ID is treated like cookies in terms of the browser's cookie management
> policy. We should investigate whether we could improve the privacy
> protections for this mechanism to make sure it doesn't become a
> new/better way to track people.

Is it fair to say that, the way the Chrome team have implemented it, it
is an _equivalent_ way to track people, and your aim is to make it a
_less_good_ way? Or do you think that the current implementation is a
better way, and you aim to make it equivalent?

> Ideally, we would know which cookies
> were associated with a login event (username/password submission,
> Persona/BrowserID login, etc), and then only generate and use a
> Channel ID keypair in those situations. However, this would require us
> to be able to classify cookies into "authentication" and "tracking"
> buckets, which is something that we probably cannot do perfectly and
> automatically.

Is there even such a distinction? An authentication cookie can also be
used for tracking.

Could we make things better by refusing point blank to do third party
channel IDs? We don't have a legacy problem like we do with cookies.

> Because this mechanism would require changes to both
> clients and servers for it to be effective, it seems reasonable that
> we could require servers that want to use Channel ID to do something
> special when the user logs in, if needed. And/or, we may be able to
> repurpose some of the password manager login detection logic to detect
> when to start using ChannelID for a server.

This logic is not enormously robust (although it's been rejigged
recently, IIRC).

Gerv