Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did. WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application?
This is more flexible and may involve separate APIs, new off-by-default flags in the existing APIS, whatever else makes sense for a particular TLS implementation… Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Tuesday, June 13, 2017 5:27 AM To: Salz, Rich <rs...@akamai.com> Cc: tls@ietf.org Subject: Re: [TLS] Separate APIs for 0-RTT On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: Microsoft also has a separate API for 0RTT data. I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two. Outlier is clearly wrong. I did not know that about Microsoft. Thanks for the update. I take back "outlier" I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one. I was intending to use wording that was neutral between the two options without any claims about popularity. Thanks, -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
