Subject: [TLS] draft-ietf-tls-tls13-21: actual early data...

From: "Le Van Gong, Hubert" <[email-masked]>
Date: Fri, 11 Aug 2017 14:56:03 -0700

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Aug 2017 15:34:45 -0700

On Fri, Aug 11, 2017 at 2:56 PM, Le Van Gong, Hubert <[email-masked]>
wrote:

> 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
> I wonder what was the rationale for not allowing the early_data extension
> to contain actual data?

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

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>