Hithere,
While looking into leveraging early data, it occurred to me that the
actual effectiveness of 0-RTT is going to be highly dependent on
implementationdetails.
In section 2.3 (Zero-RTT Data) -tls13-21 [1], the first sentence says
"TLS 1.3 allows clients to send data on the first flight ("early data")"
which I initially interpreted as "you can send data in the
ClientHelloitself.Part of figure 4 (reproduced below), seemed to confirm
my perceptionthat Application Data is indeed in the ClientHello msg:
--------
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*)
--------
Alas, upon experimentation (using latest OpenSSL), we've observed that
our early data (no matter how small) gets shipped in a separate TCP
packet after the TCP packet containing the ClientHello. This becomes a
significant performance hit when the underlying network stack uses
something like the Nagle algorithm (or similar [2]) because the TCP
packet with early data will only be sent *after* a server TCP ACK (for
the ClientHello) has been received by the client. So much for zero
roundtrip in that case.
It is not a lot of effort to modify the OpenSSL client (and server) to
not delay the early data TCP packet but it something not everyone will
be comfortable doing, esp. in an enterprise setting.
Looking into the data structure of ClientHello, I could not find a place
to put early data either: the ClientHello early_data extension can only
contain an empty EarlyDataIndication structure.
I wonder what was the rationale for not allowing the early_data
extension to contain actual data?
Was the intent to preserve protocol cleanliness? i.e., ClientHello is a
handshake protocol message and the early data is a Record protocol message?
Cheers,
Hubert & Jeff
[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-2.3
[2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
