Re: [TLS] Fixing TLS

[Dmitry Belyavsky <[e-mail]>]

Hello Hubert,

On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario <[e-mail]> wrote:

> On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote:
> > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann
> >
> > <[e-mail]> wrote:
> > > Yoav Nir <[e-mail]> 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.