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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
