Re: [TLS] Fixing TLS

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 14 January 2016 13:41 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99FD1B34F7 for <tls@ietfa.amsl.com>; Thu, 14 Jan 2016 05:41:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7ch4x-vVCHj for <tls@ietfa.amsl.com>; Thu, 14 Jan 2016 05:41:42 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4731B34F9 for <tls@ietf.org>; Thu, 14 Jan 2016 05:41:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 390846B8; Thu, 14 Jan 2016 15:41:40 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id NlN9VpXAYcEk; Thu, 14 Jan 2016 15:41:39 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (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 <ilariliusvaara@welho.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20160114134136.GA24427@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160114102933.GA24088@LK-Perkele-V2.elisa-laajakaista.fi> <20160114112707.BFB721A3E9@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20160114112707.BFB721A3E9@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/t967tOjHKHNI_3AJY6V_KUWRreQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fixing TLS
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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... ]

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