User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 Build Identifier: While draft-altman-tls-channel-bindings is not yet a finalized RFC, the functionality is currently deployed by Microsoft as part of their SChannel SSPI, as it's necessary to implement "Integrated Windows Authentication with Enhanced Protection" ( http://msdn.microsoft.com/en-us/library/dd639324(VS.90).aspx ). Further, the tls-channel-bindings are referenced by a number of RFCs currently in progress ( http://www.fenron.net/~fenner/ietf/deps/index.cgi?dep=draft-altman-tls-channel-bindings ) The current version is -10, and is on track to be finalized soon ( https://datatracker.ietf.org/doc/draft-altman-tls-channel-bindings/ ) Reproducible: Always
Created attachment 443031 [details] [diff] [review] Patch against 3.12.6 adding support One new public enum is exported by this patch: SSLChannelBindingType Two new public API calls are exposed: SSL_GetChannelBinding SEC_DecodeSignatureAlgorithmOidTag I was uncertain whether it would be more appropriate to use a dynamic array for returning the types of supported channel bindings (similar to how cipher suites are supported), to facilitate protocols that may be able to negotiate amongst multiple types of bindings that may be added later, or whether to use the currently hard-coded list. Given that the selection of channel binding type may affect the strength of security offered, it seemed more appropriate to require application developers specify the type of binding they intend to request. Absent of any specific NSS coding guidelines I could find, I've attempted to adhere to http://www.mozilla.org/projects/nspr/eng-process/contributors.html . Though most of the code appeared a mix between tabs and spaces, all of the new code contained is standardized on a four-space indent style. Outputs were added to vfyserv and selfserv to output all of the available channel bindings during connection, when appropriate. I've cross-referenced the results with the Microsoft SChannel provider to verify compatibility, and will be happy to attach a patch to the Platform SDK Web Server sample code if necessary. No new unit tests were added to this code.
Comment on attachment 443031 [details] [diff] [review] Patch against 3.12.6 adding support Wan-Teh has encouraged me to review this patch.
I confirm this is an enhancement request. :)
We had need of the tls-unique binding and so there's a Chromium patch here: http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/tlsunique.patch?view=markup I wasn't aware of this bug when writing it and I'm not claiming that it's superiour.
draft-altman-tls-channel-bindings has become RFC 5929: Channel Bindings for TLS.
Are there any plans to add TLS Channel ID support to NSS? Is that the only route to support in Firefox? Looks like this one's been sitting for quite some time.
Eric: this bug is about channel bindings, which is separate (and standardized) from token bindings (new channel ID)