Hi Eric, On 02/08/15 19:52, Eric Rescorla wrote: > I'm sure there are a few other things people would like nailed down, > but I think the big issue here is whether or not we would require TLS 1.3 > or not. > I would argue for not, but i can understand why people would feel the other > way.
So I don't get the argument for allowing any earlier versions of TLS here at all. Why do you prefer that? My reasons for assuming your profile, when documented, (which it is not currently, regardless of one's familiarity with TLS) would only be a profile of TLS 1.3 were: - If you allow earlier versions, you get all the pain of backwards compatibility, the need to ensure you don't have any of the old bugs, etc. etc. - Implementations will have to be able to respond sensibly to all sorts of old crap ClientHello stuff at least, and maybe more. That will make the TCPINC profile much more complex than needed, or else, make the TCPINC profile very likely to be incompletely specified. - I think it is also likely to increase the chances of failing to successfully negotiate a session, simply on the basis of the number of twistable knobs in the various versions of TLS. For example, will there be a need for the TLS h/w accelerator bug-fixing oversized ClientHello nonsense bytes in some cases if TCPINC goes this route? - With earlier versions you lose whatever security analysis will be done for TLS1.3 which is being designed to make that kind of analysis much easier. Earlier versions are all hard to analyse, and nobody has done work on, or afaik plans work on, analysis of this profile over older various versions of TLS. - Assuming QUIC is standardised and as planned also uses a profile of TLS1.3 (albeit likely less constrained than for TCPINC), we've diverged quite oddly. - I assumed you'd want some 0-RTT stuff, much as I'm not a fan of that. - I don't see any need for almost 400 ciphersuites and all the crap that goes with those, the TLS1.3 MTI ciphersuites should be more than enough for TCPINC. (Too much in fact, IMO.) - In summary, inheriting two decades of cruft for, I think, zero real benefit, seems to me like a bad plan. There is also a major benefit in not having every WG participant having to convince themselves that the spec has successfully avoided that two decades of cruft via clever profiling. Actually the only benefit I think one can claim from allows earlier versions of TLS would be that it makes it easier for folks who currently have TLS code and want to re-use that for TCPINC. If that is your argument than a) I don't find it very compelling and b) I think it means you also need to document how it's relatively easy to take a current generic TLS implementation and make it conform to the TCPINC profile. (By "document" here I don't mean in an I-D though, that could be done just fine via code or emails arguing the case.) So - why prefer inheriting cruft? (Apologies in advance for the very loaded question:-) Cheers, S. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
