IETF Logo Mail Archive

Re: [TLS] Deployment ... Re: This working group has failed

mrex@sap.com (Martin Rex) Tue, 19 November 2013 16:21 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 43F6B1AE082 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:21:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 l-xz5Q3UH9Ok for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:21:10 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E3A341AE081 for <tls@ietf.org>; Tue, 19 Nov 2013 08:21:09 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAJGL22a008276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 17:21:02 +0100 (MET)
In-Reply-To: <e2d8b5d7303349d1be3d2f2b43cfdb30@BY2PR03MB074.namprd03.prod.outlook.com>
To: Marsh Ray <maray@microsoft.com>
Date: Tue, 19 Nov 2013 17:21:02 +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: <20131119162102.B351C1AAB6@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>, Michael Staubermann <Michael.Staubermann@webolution.de>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Tue, 19 Nov 2013 16:21:12 -0000

Marsh Ray wrote:
> 
> > The weakness of TLSv1.2 is in the RSA signatures (digitally signed).
> > SSLv3, TLSv1.0 and TLSv1.1 were using an SHA1+MD5 combination for digitally
> > signed, which is stronger than SHA1 alone.
> > 
> > TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5),
> > and the latter is pretty far from 128-bit security.
> 
> Or am I missing something?

An MitM-Attacker could send an TLS signature algorithms extension
with only (rsa,md5) and (EC)DHE_RSA cipher suites to the server
to obtain large amounts of (rsa,md5) signed (EC)DHE parameters
and then try to have the client accept (rsa,md5) signed (EC)DHE
parameters.  This is entirely independent of the signatures on
the certificates.

> 
> Are you saying that TLS 1.2 clients in practice MUST send md5 and sha1
> in supported_signature_algorithms, even if they trust no MD5 or SHA-1 roots?

This isn't about the highest security level that cooperating TLS peers
might achieve, but the lowest security level that an MitM attacker can
coerce the peers to perform.


The TLS v1.2 signature algorithms extension should have NEVER conflated
"digitally-signed" algorithms with signatures on certs, and it should
have NEVER allowed anything less than SHA1+MD5 with rsa for use in
digitally signed.  We can re-use the digitally-signed TLSv1.2 PDU
changes to make the signalling available in all versions of TLS,
but the TLSv1.2 signature extension in ClientHello is for the trashcan.

-Martin

v2.23.0 | Report a Bug | By Email