On Fri, Aug 11, 2017 at 2:56 PM, Le Van Gong, Hubert <hub...@levangong.org>
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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
