Ilari Liusvaara wrote: [ Charset UTF-8 unsupported, converting... ] > 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.
Nope, TLS extensions (rfc3546, jun-2003) are not required, and were not part of TLSv1.0 (rfc2246, jan-1999). TLSv1.0 contains only a forward-compatibility notice as a comment to the ClientHello PDU. The same notice that was retrofitted to the carefully hidden SSLv3 specification from November 1996 that was used as a starting point for the TLSv1.0 spec. But we all know how little interop was tested for this forward compatibility notice, similar to the untested protocol versions > { 3, 1 } (aka TLSv1.0). > > > > > > > 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. 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, It is a real pity that neither TLSv1.1 (rfc4346,apr-2006) nor TLSv1.2 (rfc5246,aug-2008) did not prohibit the dangerous PKCS#1 v1.5 processing entirely, because that's an extremly low hanging fruit. > >> - 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. > > > - 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. > > 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? Yup. What TLSv1.2 (rfc5246) should have done in 2008 already. > >> - 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? The client remains free to perform local policy enforcement for any *incoming* data from the server. The extreme nuisance with rfc5246 is what Microsoft has shipped in SChannel, where an extensionless ClientHello offering TLSv1.2 will cause a Microsoft Server (2008&2012) to choke and abort the TLS handshake when the server has only a server certificate signed with sha256withRSAEncryption, wereas it will handshake successfully (and negotiate TLSv1.1) if the very same client offers only TLSv1.1 or offers TLSv1.2 in an SSL Version 2 CLIENT-HELLO. > > And then: > > - Imply Extended Master Secret. > - Require Renego fixes. wfm. > > - 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). -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls