508184 - Implement TLS keying material exporters in Mozilla Firefox

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Douglas Stebila]

Attachment: Patch implementing keying material exporters in Javascript

TLS keying material exporters
(http://tools.ietf.org/html/draft-ietf-tls-extractor-06) allow additional
keying material to be derived ("exported") from the master secret used in the TLS (a.k.a. SSL) connection; this
exported keying material can then be used at the application layer for a
variety of purposes.  It would be good if Mozilla eventually had support for this.

A patch exists already for implementing keying material exporters in NSS (see bug #507359).

This bug is for exposing the keying material exporter at the Mozilla application layer via Javascript.  In particular, it introduces a new method called window.crypto.tlsExportKeyingMaterial(label, numBytes, contextValue), where contextValue can be null.  This method name or signature is not standardized anywhere.

FYI, I have also implemented this for OpenSSL/Apache/PHP, and a patch for that is
available at http://www.douglas.stebila.ca/code/keying-material-exporters/ in
case interoperability testing is desired.

Comment 1

[Eric Rescorla (:ekr)]

Attachment: Updated patch to match HEAD

Note: I just ported this patch. I have not reviewed the original patch in any meaningful day.

Comment 2

[Eric Rescorla (:ekr)]

Attachment: This time marked as a patch

Comment 3

[Ludovic Hirlimann [:Usul]]

Comment on attachment 597805 [details] [diff] [review]
This time marked as a patch

Eric thanks for updating the patch. You also need to set review flags if you want this to go forward. Asking review to brian.

Comment 4

[Wan-Teh Chang]

Comment on attachment 597805 [details] [diff] [review]
This time marked as a patch

Eric: you attached the NSS patch to the wrong bug.  This bug
is about the JavaScript interface.  The NSS bug for TLS
keying material exporter is bug 507359.  In any case, it's
not necessary to attach a new patch.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

We should have a new component for DOMCrypt (window.crypt).

It seems reasonable to me to expose this to JS, especially for use with the rest of DOMCrypt. But, the returned key material should probably be a key object as defined by DOMCrypt.

However, there are some issues w.r.t. offline use and connection management. For an HTTPS page, we might not have a valid SSL connection at all, if we loaded it from the cache. And, also, we might have MULTIPLE SSL connections for a host for which we send requests and receive responses, and each of those connections might be in a different SSL session. And/or the connection from which we loaded the page might not be open anymore. All of these connection management issues need to be specified before we can move forward with it.

Douglas, I looked at your patch. Besides the big connection management issue, there is also a thread-safety issue: generally, in Firefox we can only access SSL sockets on the socket transport service thread, not on the main thread where this code runs.

Comment 6

[Daniel Kubec]

Is there anybody working on this right now ? 

I made proof of concept of TLS "second channel authentication" for openssl and nss. I PRELOAD some api functions without modifing any source code. I catching handshakes and using RFC5705 material exporters. (multiple scenarios were tested including apache2/mod_ssl vs firefox)

I amd tryin to resolve issue "multiple TLS sessions/connections" with "Origin-Bound Certificates: Now called "Channel ID" "

Origin-Bound Certificates: Now called "Channel ID"
http://permalink.gmane.org/gmane.ietf.tls/9824
Transport Layer Security (TLS) Channel Ids draft-balfanz-tls-channelid-00
http://tools.ietf.org/html/draft-balfanz-tls-channelid-00

This should imho simplify issue when client/browser using one TLS Session based using Origin-Bound Certificates identity (or other client certificate ) for connection with same server.

Server will identity client by certificate and authentificate new connections automatically when there is primary TLS channel with this peer allready.

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler]]

There's no clear use-case for this nor any particular party driving its implementation -> wontfix (this isn't to say that this will never happen, but rather to reflect that we are not working on this and we do not plan to).