>jQcmQRYFpfptBannerEnd >> Those who can move to 1.3+, will do so, regardless of this draft. Those who >>can’t, would
>> do whatever’s appropriate in their case – again, regardless of this draft. > > Same as for any other IETF document. :) :-) Yes, but not quite – as other IETF documents (usually) provide more of (IMHO) useful information. This one is (IMHO) a pure attempt of “legal spit”. > One difference in the current wording is that it would become trivially more >difficult to get a multi-vendor > PQ solution for current TLS 1.2 implementations. Yeah, a great accomplishment, indeed. Authors can be proud. :-( > Assuming, of course, that “just use what was defined for TLS 1.3 or later” > somehow > doesn’t occur to everyone. My starting assumption here is that the majority of people implementing TLS and/or deciding what to authorize for deployment TLS-wise, are not stupid, and understand the benefits of the newer protocol version, including its added security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying with 1.2. With the additional advantage of being aware of their CONOPS- and use-case-specific circumstances. I have seen real (and important enough) cases where that kind of upgrade was infeasible, so the authorities chose to “accept the risk”. (And no, I cannot post details – so no need to bother asking.) TNX
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
