On Sun, Mar 13, 2016 at 09:26:14PM -0400, Harlan Lieberman-Berg wrote:
>
> I agree with a slight tweak in wording here, Bill. I think that we
> /should/ drop the parts of 0-RTT where we are not confident that an
> admin who blindly enables functionality in TLS 1.3 will not end up
> harming themselves.
>
> More generally, I strongly believe that TLS 1.3 should not
> provide options which we think should be restricted to "admins who know
> what they're doing". These end up hurting us down the line (cf EXPORT
> cipher suites.)
>
> I think we should ship the parts of 0-RTT that we believe are
> intrinsically safe for (the vast majority) of the internet to enable and
> use on day 1.
Here are what I think would be reasonable restrictions on 0-RTT:
- Require labeling the application protocol 0RTT data is for.
* To prevent cross-protocol attacks.
- Require application protocol to profile the semantics of 0RTT data.
* To at least get some idea of protocol-level security properties.
* Some applications might need to handle 0RTT specially for
security reasons (HTTP/2?)
- Require application to specifically request 0RTT data.
* To prevent unaware applications from thinking it has the same
properties as main data.
- Require 0RTT data to be kept separate from main application data.
* To make more difficult for applications to mix it up.
- Ensure that no 0RTT mode invokes screwy cryptographic behaviour.
* Famous last words: "Not believed to be exploitable".
And none of these should be subject to "admin configuration"
(disabling entiere 0-RTT is).
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
