1421572 - Early exporters don't include ClientHello

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement)

Description

[Martin Thomson [:mt:]]

Peter Wu caught this: we aren't currently folding ClientHello into the early exporter secret.  This was a pretty serious oversight, which would have made QUIC interop a fun exercise.  Also, we would have had key synchronization.

Comment 1

[Phabricator Automation]

Comment on attachment 8932799 [details]
Bug 1421572 - Correct early exporter secret derivation, r?ekr

Peter Wu has approved the revision.

https://phabricator.services.mozilla.com/D297#7209

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

Hi Martin, what is the security impact of this? We'd like to rate it.

Comment 3

[Peter Wu]

The early exporter secret was only determined by the PSK, an attacker would be able to modify the Client Hello message containing the PSK extension followed by 0-RTT data and the server would not reject it. The attacker cannot modify nor read the 0-RTT data though.

Specifically for QUIC, this would allow the negotiated QUIC version in the quic_transport_parameters Client Hello extension to be modified, resulting in a different interpretation of QUIC 0-RTT packets on the server side. Note that the 1-RTT handshake cannot be completed in this case.

It does not affect TLS application data (such as HTTP/2) because the export secret is not used there.

It has some integrity impact for applications using the TLS Exporter (both of them must use NSS), but I don't know if such applications exist.

Comment 4

[Martin Thomson [:mt:]]

mwobensmith: Let's say sec-low based on Peter's analysis.  I don't believe that anyone is using this right now, otherwise we'd hear about the interop problems: NSS wouldn't talk to another implementation successfully.

Comment 5

[Matt Wobensmith [:mwobensmith][:matt:]]

OK, thanks Martin and Peter.

Comment 6

[Martin Thomson [:mt:]]

https://hg.mozilla.org/projects/nss-try/rev/401de5188538