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) _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
