IETF Logo Mail Archive

Re: [TLS] consensus on backwards compatibility changes

mrex@sap.com (Martin Rex) Wed, 28 January 2015 20:42 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 7850D1A036C for <tls@ietfa.amsl.com>; Wed, 28 Jan 2015 12:42:43 -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 gVIb2yLvtveW for <tls@ietfa.amsl.com>; Wed, 28 Jan 2015 12:42:39 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238721A005C for <tls@ietf.org>; Wed, 28 Jan 2015 12:42:39 -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 smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id E42513A35F; Wed, 28 Jan 2015 21:42:36 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D774442D63; Wed, 28 Jan 2015 21:42:36 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CA94B1B130; Wed, 28 Jan 2015 21:42:36 +0100 (CET)
In-Reply-To: <54C8D548.2020101@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Date: Wed, 28 Jan 2015 21:42:36 +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: <20150128204236.CA94B1B130@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hz97bDyMynVCu1wvrgZfalyAtpA>
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] consensus on backwards compatibility changes
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: <http://www.ietf.org/mail-archive/web/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: Wed, 28 Jan 2015 20:42:43 -0000

Florian Weimer wrote:
> Dave Garrett wrote:
>> With regard to this topic, please see the previous discussion on list.
>> (the "drop obsolete SSL 2 backwards compatibility" thread)
>> Implementers have specifically pushed back against dropping all
>> SSL 2 stuff, in particular because they think it is valid to still
>> negotiate TLS 1.2 using an SSL version 2.0 client hello.
> 
> But if you do this, the handshake uses SHA-1 only, per section 7.4.1.4.

rfc5246 section 7.4.1.4?
I think you are misreading the TLSv1.2 specification.

The use of SHA-256 for the TLSv1.2 PRF and for the handshake message
hash that goes into the the Finished handshake message depends only
on the chosen cipher suite and the protocol (v1.2), and is independent
from whether the client sent a signature algoritm extension and what
algorithms were listed in that extension.

https://tools.ietf.org/html/rfc5246#section-7.4.9


There are several serious design flaws (resulting in serious weaknesses)
in the TLSv1.2 signature algorithm extension, however.  TLSv1.2 is the
only TLS protocol version where (rsa,md5) is a valid signature algorithm
for creating "digitally-signed" PDUs (ServerKeyExchange and
CertificateVerify), and that was a terribly stupid decision.
Even (rsa,sha1) is significantly weaker than what every prior TLS
protocol version, including SSLv3 had been using (rsa,sha1+md5).

Since the TLSv1.2 signature algorithm extension semantics have been so
terribly misspecified, it will take quite a while before TLSv1.2 clients
can safely remove (rsa,sha1) from ClientHello (unless they continue
doing reconnect fallbacks after handshake failures, aka downgrade dances).

I would not have imagined something as broken as the TLSv1.2 signature
algorithms extension would (a) get proposed and (b) get standardized,
but it happened, as you can see in rfc5246.  When I noticed the
brokenness when reading rfc5246, I hoped that implementors would
recognize the obvious security problem and refuse to implement it.
Well, some hearts don't miss a single bleed.


-Martin

v2.23.0 | Report a Bug | By Email