Re: [TLS] Fixing TLS
mrex@sap.com (Martin Rex) Thu, 14 January 2016 11:27 UTC
Return-Path: <mrex@sap.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 1232C1B336D for <tls@ietfa.amsl.com>; Thu, 14 Jan 2016 03:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnzsLwGZSzj4 for <tls@ietfa.amsl.com>; Thu, 14 Jan 2016 03:27:10 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E011B336B for <tls@ietf.org>; Thu, 14 Jan 2016 03:27:09 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (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 http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id CD51640406; Thu, 14 Jan 2016 12:27:07 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id BFB721A3E9; Thu, 14 Jan 2016 12:27:07 +0100 (CET)
In-Reply-To: <20160114102933.GA24088@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Thu, 14 Jan 2016 12:27:07 +0100
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: <20160114112707.BFB721A3E9@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ynLD-QCXbu206z1zFFhkst8F9XE>
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
Reply-To: mrex@sap.com
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 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 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] 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