Hi, > > I expect that you are familiar with > draft-camwinget-tls-ns-impact > which looks at operational security with TLS 1.2 and identifies what is > difficult or impossible to do with TLS 1.3. One might infer from this I-D > that TLS 1.3 offers less security than TLS 1.2:-)
One requirement that was raised in the later stages of the work on TLS 1.3 > related to audit, and was raised, I think, by representatives of the > finance industry; the WG rejected the requirement. Since then, I have seen > suggestions on the TLS and other I am familiar with the discussion and the 3-4 issues stated in that I-D, yes. An alternative to TLS 1.3 has indeed been proposed by the finance industry that partially solves it: https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf <https://trello.com/c/HctoUsA5/11-etls-final-standard-https-wwwetsiorg-deliver-etsits-103500103599-10352303-01010160-ts10352303v010101ppdf> > lists, and in the press, about the development of alternative protocols to > meet the requirements that TLS 1.3 does not. Hence my reference to > fragmentation. (I think the I-D covers that under offline analysis). > Although the I-D focusses on Operational Security, I think that much of > what it says is applicable more generally. > Any fragmentation remains speculative, so far. I would in fact not be surprised if eTLS remains completely unused outside mobile phone banking apps and inter-bank communication. I definitely do not expect it in user traffic as the browser makers have been clear they won't support anything that does static RSA and/or static DH. If anything at all, though, that would be an argument in favour of a BCP - note that this BCP is not TLS 1.3-specific. It still covers TLS 1.2. (And even there, there is a need for crypto updates!) > The I-D that we are being asked to adopt lacks any detail about what the > bis might change i.e. we are being asked to approve a blank slate which > might end up saying how great TLS 1.3 is and how we should move to it as > soon as possible; to which the I-D I mention offers an alternative > viewpoint. > I would not preempt discussions in such a way. Last time, they were extremely productive, with folks making sure that all sorts of interop issues were addressed. Ralph
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
