On Thu, May 04, 2017 at 02:37:20PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <[email protected]> wrote: > > [...] > > I think this is basically right. In the PR I just posted, I spent most of > my time describing the > mechanisms and used a SHOULD-level requirement to do one of the mechanisms. > I think there's a bunch of room to wordsmith the requirement. Perhaps we > say: > > - You can't do 0-RTT without an application profile > - Absent the application profile saying otherwise you SHOULD/MUST do one of > these mitigations?
There's a number of ways to handle this. One is to say that 0-rtt cannot be enabled by default, and that enabling it requires an API call or application profile that puts the onus of understanding the ramifications on the application developer. The thing to keep in mind is that this RFC can give guidance to TLS implementors, and to authors of Internet protocols using TLS. It can't really give guidance to authors of non-Internet protocols using TLS: they might never look at the RFC. So the guidance here has to be for the available audience. For TLS implementors the guidance should be to make the 0-rtt footgun clear to consuming applications. Nico -- _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
