Re: [TLS] Fixing TLS

Ilari Liusvaara <> Thu, 14 January 2016 13:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C99FD1B34F7 for <>; Thu, 14 Jan 2016 05:41:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j7ch4x-vVCHj for <>; Thu, 14 Jan 2016 05:41:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4E4731B34F9 for <>; Thu, 14 Jan 2016 05:41:41 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 390846B8; Thu, 14 Jan 2016 15:41:40 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id NlN9VpXAYcEk; Thu, 14 Jan 2016 15:41:39 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E63F1138; Thu, 14 Jan 2016 15:41:39 +0200 (EET)
Date: Thu, 14 Jan 2016 15:41:36 +0200
From: Ilari Liusvaara <>
To: Martin Rex <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
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 13:41:45 -0000

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


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