> On May 9, 2017, at 12:00 PM, Salz, Rich <rs...@akamai.com> wrote:
>
> To me, the argument against this comes down to this: The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.
What would a receiver API then look like? Would it be something like:
* Repeatedly request 0-RTT data until none-remains, if none expected
or desired, fail if any found.
* Then repeatedly request 1-RTT data via existing TLS APIs
* Fail if 1-RTT data is requested and not all the 0-RTT data has yet
been consumed?
Or did you have something else in mind? What are your thoughts on the
sender side? Just enable 0-RTT and have the toolkit send as much 0-RTT
data as "fits" and the rest 1-RTT, or an explicit request for a specific
0-RTT payload?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
