On Tue Feb 23 19:28:12 2016 GMT-0800, Watson Ladd wrote: > On Tue, Feb 23, 2016 at 5:49 PM, Stephen Farrell > <[email protected]> wrote: > > > > > > On 23/02/16 22:37, Hugo Krawczyk wrote: > >> > >> (In particular, if these semantics may be based on stuff that happens > >> outside TLS, as Karthik and Watson were pointing out, then maybe we really > >> put a "Surgeon General" warning on 0.5 data of equal size to that of > >> 0-RTT.) > > > > That, and/or also do a significant amount of work to consider other > > application uses of TLS that aren't well represented by folks who > > participate in the development of TLS1.3. And also oddities like > > EAP-TLS about which I at least am mostly ignorant but where I'd bet > > there's "fun" to be had with 0rtt. > > Applications shouldn't use 0RTT unless they are absolutely, > positively, sure it won't be a problem. It's up to them to determine > what the danger is, and up to us to explain what the (minimal) > properties provided are. If they rely on extensions then either those > extensions need to be included in the security proofs, or we need to > make clear that they are not as secure as TLS 1.3, and that > implementations which enable both of them can get completely wrecked > in new and exciting ways. > > > > > And we have to do that recognising that regardless of what the RFC > > says, if developers can improve performance by calling tls_send0() > > and not tls_send(), they will do the former. IOW, if we are going > > to define dangerous implements, (e.g., with replayable data) then > > I think the onus is mostly on us to know what bad effects those > > might have before we've done a good job. (We can try do that at > > IETF LC, but doing so isn't common and is often messy if we end up > > surprising folks.) > > But will they call tls_send_data_replayable? or > tls_send_data_dangerously?
Sadly, yes, they will, I think. Evidence welcome though. It is a big and imperfect world. S. > API designers need to mark dangerous > functions accordingly. (They also need to make APIs easy to use: yes, > I am blaming the OpenSSL developers for their repeated and continued > failures to do this) > > > > > Cheers, > > S. > > > > > > _______________________________________________ > > TLS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
