On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote: > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann > > <pgut...@cs.auckland.ac.nz> wrote: > > Yoav Nir <ynir.i...@gmail.com> writes: > > To expand on this, I'll take Ilari Liusvaara's comments: > >>Bleeding edge ideas? They essentially re-invented SIGMA, which is > >>over 10 years old. The basic framework for doing 0-RTT is the > >>obvious one. The only new algorithm prsent since TLS 1.2 is HKDF, > >>which is just 5 years old. > >> > >>So I don't see anything "experimential" ideas, mechanisms or > >>algorithms in there > >> > > When SSLv3 was introduced, it also used ideas that were 10-20 years > > old (DH, RSA, DES, etc, only SHA-1 was relatively new). They were > > mature algorithms, lots of research had been published on them, and > > yet we're still fixing issues with them 20 years later (DH = 1976, > > SSLv3 = 1996, Logjam = 2015). > We all understand that the security of a protocol is not a function > not of the primitives but of the way the protocol works. The confusion > between export and nonexport DH shares was noted almost immediately > in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a > discovery in 2015, given that the reasons for this were all worked > out in the early 90's. So no, Logjam is not a result of unknown > issues appearing after 20 years, but ignoring known issues. > > > TLS 2.0-called-1.3 will roll back the 20 years of experience we have > > with all the things that can go wrong and start again from scratch. > > SIGMA, at ten years old, is a relative newcomer to DH's 20 years > > when it was used in SSLv3, but in either case we didn't discover > > all the problems with it until after the protocol that used it was > > rolled out. We currently have zero implementation and deployment > > experience with 2.0-called-1.3 [0], which means we're likely to > > have another 10-20 years of patching holes ahead of us. This is > > what I meant by "experimental, bleeding-edge". > > There is an old joke about the resume with one years experience > repeated 20 times. All of the problems in TLS have been known for > decades, as I've repeatedly demonstrated on this list. All of them > were known to cryptographers at the time TLS was being designed and > deployed. It does not take deployment to trigger analysis.
Exactly this: BEAST and Lucky 13 "possible" problem was described in the RFC itself. Same thing for the "new" Bicycle attack - described in the RFC for TLS 1.0 and repeated in each version since. So lets not repeat those mistakes - if there are possible issues, lets fix those, now. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
