Re: [TLS] Fixing TLS (Martin Rex) Thu, 14 January 2016 11:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1232C1B336D for <>; Thu, 14 Jan 2016 03:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GnzsLwGZSzj4 for <>; Thu, 14 Jan 2016 03:27:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6E011B336B for <>; Thu, 14 Jan 2016 03:27:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 162404485D; Thu, 14 Jan 2016 12:27:08 +0100 (CET)
X-purgate-ID: 152705::1452770828-00002D85-3C786464/0/0
X-purgate-size: 5993
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id CD51640406; Thu, 14 Jan 2016 12:27:07 +0100 (CET)
Received: by (Postfix, from userid 10159) id BFB721A3E9; Thu, 14 Jan 2016 12:27:07 +0100 (CET)
In-Reply-To: <>
To: Ilari Liusvaara <>
Date: Thu, 14 Jan 2016 12:27:07 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Fixing TLS
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jan 2016 11:27:12 -0000

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

> And then:
> - Imply Extended Master Secret.
> - Require Renego fixes.


> - 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).