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

Marsh Ray <maray@microsoft.com> Tue, 19 November 2013 05:44 UTC

Return-Path: <maray@microsoft.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 68F6F1AC4A3 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VA-4zmtTBbb5 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:44:50 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0153.outbound.protection.outlook.com [207.46.163.153]) by ietfa.amsl.com (Postfix) with ESMTP id F3BC31AD9B7 for <tls@ietf.org>; Mon, 18 Nov 2013 21:44:49 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB073.namprd03.prod.outlook.com (10.255.241.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 05:44:42 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.133]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 05:44:42 +0000
From: Marsh Ray <maray@microsoft.com>
To: "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: AQHO5JP/WVAZL/KMwUmZ2rNHZIm1mporjnaAgAAESACAAAJXgIAAFwMAgAAAZACAAFnG8A==
Date: Tue, 19 Nov 2013 05:44:41 +0000
Message-ID: <e2d8b5d7303349d1be3d2f2b43cfdb30@BY2PR03MB074.namprd03.prod.outlook.com>
References: <20131119000224.D46E41AAB1@ld9781.wdf.sap.corp> <20131119000348.17FC91AAB1@ld9781.wdf.sap.corp>
In-Reply-To: <20131119000348.17FC91AAB1@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [76.121.57.187]
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(189002)(199002)(87266001)(31966008)(74662001)(2656002)(63696002)(74502001)(74706001)(81686001)(46102001)(81342001)(81542001)(74876001)(85306002)(69226001)(54316002)(56776001)(47446002)(59766001)(51856001)(77982001)(76482001)(83322001)(83072001)(56816003)(54356001)(19580395003)(49866001)(47736001)(4396001)(53806001)(47976001)(50986001)(66066001)(79102001)(15975445006)(80022001)(77096001)(81816001)(76576001)(76786001)(76796001)(87936001)(19580405001)(65816001)(80976001)(33646001)(74316001)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB073; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:76.121.57.187; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
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
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 05:44:52 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
> 
> Resent (with correction) Sorry, I seem to be tired.
> 
> The TLSv1.1 PRF should be OK for 128-bit security strength.

TLS 1.1 https://tools.ietf.org/html/rfc4346#page-13
"   TLS's PRF is created by splitting the secret into two halves and
   using one half to generate data with P_MD5 and the other half to
   generate data with P_SHA-1, then exclusive-ORing the outputs of these
   two expansion functions together."

Good for 160 bits I figure?

TLS 1.2  https://tools.ietf.org/html/rfc5246#page-14
"   In this section, we define one PRF, based on HMAC.  This PRF with the
   SHA-256 hash function is used for all cipher suites defined in this
   document and in TLS documents published prior to this document when
   TLS 1.2 is negotiated.  New cipher suites MUST explicitly specify a
   PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
   stronger standard hash function.
"
Sounds stronger to me.

> 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.

But if the attacker can break MD5, he can exploit an MD5 cert chain, right? (e.g., Flamer)
If not, he can't negotiate the use of MD5 for signing the TLS handshake.

If the attacker can break SHA-1, he can exploit a SHA-1 trusted root, right?
If not, he can't negotiate the use of SHA-1 for signing the TLS handshake.

So TLS 1.2 just follows the convention established by the available trusted root CA. No configuration that could be stronger than SHA-1 can be weakened to SHA-1. Furthermore, no configuration that could be stronger than SHA-1+MD5 can be weakened to SHA-1+MD5.

Or am I missing something?

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?

- Marsh