[secdir] secdir review of draft-ietf-uta-tls-bcp-08

"Waltermire, David A." <david.waltermire@nist.gov> Tue, 10 February 2015 01:55 UTC

Return-Path: <david.waltermire@nist.gov>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E04D21A8ACC; Mon, 9 Feb 2015 17:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5zPnh0WdSvvE; Mon, 9 Feb 2015 17:55:26 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4361A01F0; Mon, 9 Feb 2015 17:55:26 -0800 (PST)
Received: from DM2PR09MB0224.namprd09.prod.outlook.com ( by DM2PR09MB0222.namprd09.prod.outlook.com ( with Microsoft SMTP Server (TLS) id; Tue, 10 Feb 2015 01:55:25 +0000
Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([]) by DM2PR09MB0224.namprd09.prod.outlook.com ([]) with mapi id 15.01.0081.018; Tue, 10 Feb 2015 01:55:25 +0000
From: "Waltermire, David A." <david.waltermire@nist.gov>
To: "iesg@ietf.org" <iesg@ietf.org>, "'secdir@ietf.org'" <secdir@ietf.org>, "draft-ietf-uta-tls-bcp.all@tools.ietf.org" <draft-ietf-uta-tls-bcp.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-uta-tls-bcp-08
Thread-Index: AdBE0QRTgwoPUN/4SsGTOM7zzTmiBA==
Date: Tue, 10 Feb 2015 01:55:24 +0000
Message-ID: <DM2PR09MB02247B391BD2A86482C949E0F0240@DM2PR09MB0224.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0222;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0222;
x-forefront-prvs: 048396AFA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2900100001)(229853001)(107886001)(19300405004)(76576001)(16236675004)(122556002)(46102003)(92566002)(40100003)(74316001)(66066001)(15975445007)(54356999)(33656002)(50986999)(102836002)(19580395003)(19625215002)(561944003)(99286002)(2656002)(86362001)(230783001)(87936001)(77156002)(2501002)(62966003)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0222; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_DM2PR09MB02247B391BD2A86482C949E0F0240DM2PR09MB0224namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2015 01:55:24.8126 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0222
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/WKq9es9K9RTVwFk23eUwxH5JJ-4>
Subject: [secdir] secdir review of draft-ietf-uta-tls-bcp-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2015 01:55:30 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: This proposed BCP outlines a number of security issues related to use of various revisions of TLS and DTLS. It details a number of attacks against various versions of TLS, cipher suites, and modes of operation; and provides recommendations to avoid these attacks in a way that is applicable to the majority of use cases for these protocols.

This document is generally well-written and clear in its content. I find this document to be ready with nits.

My only nit is a minor ambiguity in the text in section 4.2.1. Two of the "SHOULD" statements seem to be in conflict (#2 and #3) by my read:

#1 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the

   first proposal to any server, unless they have prior knowledge that

   the server cannot respond to a TLS 1.2 client_hello message

#2 Servers SHOULD prefer this cipher suite whenever it is proposed, even
   if it is not the first proposal.

#3 Clients are of course free to offer stronger cipher suites, e.g.,
   using AES-256; when they do, the server SHOULD prefer the stronger
   cipher suite unless there are compelling reasons (e.g., seriously
   degraded performance) to choose otherwise.

The way I read it, if statement #2 is honored, then statement #3 would not be honored, even if the stronger cipher suite is ordered before the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I don't think this is the intent!

It would be better to qualify statement #2 with regards to weaker cipher suites to avoid weaker proposals, while allowing stronger proposals.

Dave Waltermire