On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie > wrote: > > > However, if I'm in the rough about the above, (which seems > to me to be the case now) then my job as AD when I get a publication > request that includes 0rtt, will include figuring out if that's > safe or not. And I've no clue how I'll do that unless the WG > have already done some analysis of the many, many protocols > that use TLS. Note that I do not consider "use a different API" > to be a sufficient answer here (it is necessary, but not > sufficient).
It seem to me that there are several important mitigating factors here. 1. Nothing requires applications to use this feature at all. First, servers need to advertise it and are free to (a) not offer clients the ability to send 0-RTT data and (b) refuse to accept it if clients send it. Moreover, everyone I know of who is considering building a 1.3 library intends to provide that data to the server via a separate API, so the server will have to work to get it. 2. The replay issues are mostly problematic in cases that trouble maintaining consistent state (primarily distributed machines). Non-distributed systems can maintain a replay cache and refuse to accept traffic which appears to be a replay. This does not reduce the risk to zero but it significantly reduces it to state loss issues, which are easier to control for. So it would probably be useful to document some anti-replay mechanism based on the ClientHello fo such protocols. I've been worried about this for a while now, but the recant > thread started by Kyle Nekritz [3] prompted me to send this > as I think that's likely just the tip of an iceberg. E.g., I'd > be worried about cross-protocol attacks one might be able to > try with JS in a browser if the JS can create arbitrary HTTP > header fields which I think is the case. It's not generally the case without server consent. CORS prohibits the use of any non-simple headers in CORS requests without preflight. See: https://fetch.spec.whatwg.org/#concept-main-fetch and https://fetch.spec.whatwg.org/#simple-header > I'm also worried about > things like EAP-TLS and RADIUS/Diameter if used via TLS etc > where we don't necessarily have the right people active on this > list. Yes, this might be the case, though as above, I note that nothing is making those protocols use this feature, and the specification is quite clear about the risks involved here. Rather than requiring some open-ended exploration of the impact on every protocol of this feature, I think it would be far more sensible to require that protocols not use 0-RTT absent some specific application layer profile describing when and why it is safe. That allows the experts in those protocols to do their own analysis, rather than somehow making it the responsibility of the TLS WG. I agree that this is a sharp object and I'd certainly be happy to have such a requirement in 1.3. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
