On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote: > Ilari Liusvaara wrote: > > > > To actually fix the known problems with TLS 1.2, you would at minimum > > need a new extension, since there is currently no way to fix the broken > > server authentication. > > One Boolean signaling is sufficent to fix all of the problems. > one SCSV in the Client->Server direction and a TLS extension Boolean > response in ServerHello.
Just stick it as an extension. Extensions have been required since TLS 1.0, its precessor SSL 3.0 is _dead_. And extension-intolerant servers are just plain problems for everybody. > > > > Then there are the other security fix extensions (at least three already). > > Those all would need to be impiled. > > > > And then there is the TLS 1.2 Diffie-Hellman issue... > > TLS 1.2LTS should fix them all at once, including: > > - promise to support minimum DHE key lengths >= 2048 bits > whenever ClientHello includes DHE cipher suites The problem is that client that tries to be secure will just abort if it receives DHE <2048 bits. Regardless if server accepted the extension or not. 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. > - 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. Or do you mean that there are broken endpoints that can't mix-and- match ECDHE curves and signatures? (I know about problems doing mix-and-match on hashes and curves in ECDSA... TLS has currently no way to signal those limits). > - 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. This also causes problems for anyone trying to support DHE in TLS 1.3. > - overriding any TLS record layer protocol version and > ClientHello.client_version that is less than TLSv1.2 > > - promise that digital signatures using SHA-256 are supported You mean upgrade the default SHA-1 to SHA-256? > - fix the misunderstood semantics of the signature_algorithm extension > so that it is only used as a hint to certificate selection, > but *NEVER* seen as a hard requirement (or reason for server to > abort the TLS handshake based on the signature of the server cert). The client aborts if server certificate chain won't validate due to bad algorithms, right? And then: - Imply Extended Master Secret. - Require Renego fixes. - Imply EtM on block modes. (Any others?) -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
