Hiya, I mostly agree with what you wrote about specific mitigating factors for specific potential threats.
For this thread though, maybe we're better talking about how we might get to where we can be confident that replayable data in TLS1.3 won't cause significant harm. I'm happy to talk more about the specifics as well but maybe better to try figure out what are a good set of goals first (or in parallel). I think this bit maybe captures where you and I might most come from different perspectives: On 13/03/16 12:38, Eric Rescorla wrote: > > Yes, this might be the case, though as above, I note that nothing is making > those protocols use this feature, Sure. Except we *know* that people will see a new API and will use that to go faster, even if they ought not. TBH, I really don't think the API approach is sufficient by itself. > and the specification is quite clear about > the risks involved here. Rather than requiring some open-ended exploration "requiring open-ended" doesn't match what I'm asking for. I can understand your concern though. I'm trying to figure out how we (the IETF) get to where we are confident that we understand the important impacts of introducing this dangerous implement. As I said, I am puzzled as to how we get there and am asking that the WG help figuring that out before we get to when tackling issues we find gets harder. > 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. I think some such statement would help for sure. I'm not sure though if it's really sufficient. Even if 0rtt was to be in a separate RFC (I forget if the WG considered that) the issue is that libraries will all include it (as it'll make the web go faster) so implementers are liable to turn it on anywhere really. > 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. So again, I totally understand the reluctance to consider all of the foo/TLS options within the TLS WG. And I don't even know how one might get that done if one wanted. (Hence my asking the WG.) However, it is the TLS WG that is introducing the dangerous implement and as part of a protocol revision that is mainly intended to improve security. It seems fair to say that that may be a surprise for folks who just want to use TLS. My guess would be that if we say to all the WG's doing foo/TLS that they need to write a new document before they safely can move from TLS1.2 to TLS1.3, they'll answer back that the TLS WG should have done some or all of that before introducing the dangerous implement. There are at least two bad approaches here I think. One is "higher layers need to do all the work to figure out if moving from TLS1.2 to TLS1.3 is safe." Another is "the TLS WG needs to figure out and say if foo/TLS1.3 is safe for all <foo>." My issue is that I don't know what middle-ground here is reasonable and gives us sufficient confidence that TLS1.3 with the dangerous implement is safe enough. Cheers, S.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
