Hello Hubert, On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario <hka...@redhat.com> wrote:
> 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. > But we should leave the description of the fixed problems somewhere to avoid them in future.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
