* My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the future * and that being extra careful here is important… :)
I agree with this assessment. A MUST would certainly work for me. There are two reasons I suggested SHOULD: 1. A MUST would be non-enforceable (a TLS client or server can’t enforce the use of a particular API by the peer). 2. There’s lack of consensus on the topic of 0RTT and I’m trying to suggest a compromise😊. Cheers, Andrei From: Benjamin Beurdouche [mailto:[email protected]] Sent: Tuesday, June 13, 2017 9:50 AM To: Eric Rescorla <[email protected]> Cc: Rich Salz <[email protected]>; ML IETF TLS <[email protected]>; Andrei Popov <[email protected]> Subject: Re: [TLS] Separate APIs for 0-RTT Please forgive me for this naive question, but is there a specific incentive for using “SHOULD” instead of “MUST" only enable 0-RTT application data upon explicit opt-in by the application... My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the future and that being extra careful here is important… :) Best, Benjamin On Jun 13, 2017, at 6:12 PM, Andrei Popov <[email protected]<mailto:[email protected]>> wrote: 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
