Option to disable TLS 1.3 EndOfEarlyData message
Categories
(NSS :: Libraries, enhancement)
Tracking
(Not tracked)
People
(Reporter: mt, Assigned: mt)
Details
Attachments
(1 file)
QUIC introduces datagram transport for TLS in an odd way. Part of the integration includes this:
As a result, EndOfEarlyData does not appear in the TLS handshake transcript.
I wrote that text, so when I failed to implement this correctly (instead preferring to suppress the message), that's not great.
I am going to propose a new option rather than an experimental API, but I'm happy to listen to thoughts on alternatives. We used an experimental API for the DTLS 1.3 compatibility hack, but that is largely down to that being temporary. This shouldn't be temporary and the cost of messing this up is just that we burn a number, which we can do easily.
|
Assignee | |
Comment 1•4 years ago
|
||
This adds the ability to disable EndOfEarlyData.
On the client this is relatively simple, you just turn the message off.
The server is complicated because the server uses this to drive the installation
of the right keys. Without it, things get very messy. Thus, I have decided
that this is best left to the SSL_RecordLayerData interface. That needs an ugly
hack in order to let the new data to pass, but the damage is otherwise
relatively minor, apart from one obvious thing.
We never really built the SSL_RecordLayerData API to take application data. It
only did that to support testing of the functions. Now that we have to deal
with this new wrinkle, adding support for 0-RTT is necessary. This change does
that. That requires a barrage of new checks to see if application data is
acceptable. And then early data is captured in a completely different way,
which adds another layer of awfulness.
Note that this exposes us to the possibility that Certificate or Finished are
received in early data when using SSL_RecordLayerData and this option. I don't
think that fixing that is worthwhile as it requires tracking the epoch of
handshake messages separate to ss->ssl3.crSpec and the epoch only really exists
on that API so that applications don't accidentally do bad things. In QUIC, we
specifically block handshake messages in early data, so we have ample
protection.
|
||
Comment 2•4 years ago
|
||
Description
•