Re: [TLS] 0.5 RTT

On Tue Feb 23 19:28:12 2016 GMT-0800, Watson Ladd wrote:
> On Tue, Feb 23, 2016 at 5:49 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> 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
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> 
> 
> 
> -- 
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>