On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or > 2.0) that this WG is working on right now, why? > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other > $protocolv$(major-1).$(minor+1).
Note that these are not security protocols and they don't benefit from a formal analysis of a protocol. Such an analysis takes several years to be done and it often applies to small parts of the protocol. Switching to a new version invalidates all the existing analysis. That is of course not necessarily bad, but as we are moving towards formally verified protocols it is very bad to give these two options: 1. Stay with a formally verified but with known vulnerabilities protocol 2. Switch to a new unknown protocol which has not been studied by as many cryptographers but is _believed_ to solve the issues found in TLS. > Any TLS library that exists now doesn’t have an implementation of > either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to > get an upgraded version of your favorite library. So the upgrade path > is no smoother for either protocol. If this had been brought up > before the work on the current draft started, maybe we would be > convinced. As it is, I don’t see the point. The main problem of TLS 1.2 is that it is vulnerable to cross-protocol attacks and there is no way to mitigate that. There was such an attack described in 2012 and another in 2015 [0]. Whether there will be a new one in 2017 is an open question. Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill. That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite of the code base. Given that the majority of the issues in TLS implementations are in the code bases and not in the protocol, it is very risky to switch to such a new version just like that. For old systems it most likely will never happen and they will remain vulnerable. [0]. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
