Re: [TLS] Fixing TLS

[Ilari Liusvaara <[e-mail]>]

On Thu, Jan 14, 2016 at 12:27:07PM +0100, Martin Rex wrote:
> Ilari Liusvaara wrote:
> [ Charset UTF-8 unsupported, converting... ]

Pfft...

> > Then there's also similar problems with RSA. And then RSA PKCS #1
> > v1.5 encryption is on just about every "do not use!" list. Get it
> > wrong (good luck getting it right) and it is game over.
> 
> Getting PKCS#1 v1.5 right is fairly easy, and requiring it should go into
> TLS 1.2LTS as well.  How to do it right for signatures has been
> described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) already,

I was talking about encryption, not signatures. Those are used by
TLS_RSA_WITH_* ciphersuites. The encrpytion is very broken, the
signatures are at most slightly such.

(And those lists of crypto algorithms don't list RSA PKCS #1 v1.5
signatures the same as encryption).

> >>    - promise to support a certain small subset of EC curves
> >>      and uncompressed point format whenever ClientHello includes
> >>      ECDHE cipher suites (but may omit TLS extensions).
> > 
> > You have EC formats extension already.
> 
> rfc4492 is severly broken, in that it specifies that a ClientHello
> without the two TLS EC extensions indicates that the client supports
> *EVERYTHING* in the rfc4492 spec (rather than a reasonable default
> subset).  I hope that the IESG does not let such obvious breakage
> enter the standards track.

Does RFC4492bis fix that?
 
> > 
> > >    - new/improved ServerKeyExchange handshake message, which
> > >      does not only contain the reasonable set of DHE parameters,
> > >      but also uses a digititally signed covering all prior
> > >      handshake messages, not just the two hello randoms.
> > 
> > You mean fixing the DHE groups? Because the present arbitrary groups
> > are source of many problems.
> 
> I would be OK with implying support for a reasonable small set of
> (assumed) secure fixed groups.  But ServerKeyExchange for DHE needs
> to be fixed to allow arbitrary groups as well.  They're a performance
> problem, so I assume the marketplace will decide.  After the severe
> problems of DHE had been publicly described on the TLS mailing
> list in 2008, I decided that we will never support DHE in our
> (then OEM) implementation, and never regretted that decision.
> We've recently addes support for ECDHE, but will not support DHE.

It currently allows arbitrary groups, and all the nasty problems that
come with those.

 
> > - Imply EtM on block modes.
> 
> Personally, I do _not_ like this one.
> DTLS implementers that followed the poor advise from the DTLS spec
> might want this one, though.
> 
> I would strongly prefer (pad,mac,encrypt), as originally proposed by
> Vaudenay, because it is safer and more secure in TLS.
> 
> EtM is bad for support, because it can more easily result in corrupted
> plaintext while not showing up as error at the TLS level -- and the application
> will not necessarily notice this.  I've already seen this happening in the real
> world with AEAD (AES-GCM) in TLS (occasional encryption failures).

P-E-M would be yet another mode...


Then there is fun question of proving all this secure. I'm way less
comfortable with this than TLS 1.3 security-wise.


-Ilari