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
- [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Yoav Nir
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Peter Bowen
- Re: [TLS] Fixing TLS Watson Ladd
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Peter Bowen
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS David Benjamin
- Re: [TLS] Fixing TLS Bill Cox
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Andrei Popov
- Re: [TLS] Fixing TLS Bill Cox
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Tony Arcieri
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Kurt Roeckx
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Watson Ladd
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Nikos Mavrogiannopoulos
- Re: [TLS] Fixing TLS SCHWARZ, Albrecht (Albrecht)
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Dmitry Belyavsky
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Salz, Rich
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Martin Rex