draft-ietf-tls-tls13-21: actual early data...

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

draft-ietf-tls-tls13-21: actual early data...

Le Van Gong, Hubert
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
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: draft-ietf-tls-tls13-21: actual early data...

Eric Rescorla-3


On Fri, Aug 11, 2017 at 2:56 PM, Le Van Gong, Hubert <[hidden email]> wrote:
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*)
--------

No, it's not. That's the meaning of the phrase "first flight" as opposed to "in the ClientHello"

 
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.

This seems like a not that appropriate test: anyone who is doing 0-RTT really needs to know what they are doing (for reasons the draft lays out in pretty excruciating detail) and should at least be capable of managing their writes to TCP. It's not like they're using s_client.


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?

Amongst other things. In particular, we wanted to enable streaming of early data and then it obviously can't be part of the ClientHello, unless you want to allow it in two places. We actually did have some support for this kind of thing in early versions but it was really hard to reason about and implement.

-Ekr

 


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
[hidden email]
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Loading...