[TLS] ops review of draft-ietf-tls-sslv3-diediedie

"Fred Baker (fred)" <fred@cisco.com> Sun, 22 March 2015 06:29 UTC

Return-Path: <fred@cisco.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 A6B561A1B71; Sat, 21 Mar 2015 23:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Level:
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 qVgJUdzdyUeE; Sat, 21 Mar 2015 23:29:46 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C661A1B1C; Sat, 21 Mar 2015 23:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3695; q=dns/txt; s=iport; t=1427005786; x=1428215386; h=from:to:cc:subject:date:message-id:mime-version; bh=5lVpdEC/8mmclqnk/tKQ4N8EoPuseh2LJDLKadts1fA=; b=eoMlu3NM7vjTafGsw3VtY3GrRERY+XVou5Y7wRdF5IjKo/jTQUOdYfxi 5iGBchShw77RgQdNSXECXjwhaV2T6JSIysmi6Vz5b+9BTlqTUYvXTJLE6 S3mICu2dA72phQTj1DFEGcY34fTvtHV/acci/6pPDFNFFU/WSnT2f1YDO o=;
X-Files: signature.asc : 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AXBQCqaeJU/5BdJa1RCoMGgTCCf8UugRpDAQEBAQEBfIQTI1YSAUoCNCcEDhMGiBm3KJcNAQEBAQEBAQEBAQEBAQEBAQEbjxcGCwFQgm8ugRQFjziBWoEuhi+BGIsuhkcigX0FHIFQgXo5fwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,445,1422921600"; d="asc'?scan'208";a="405431452"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 22 Mar 2015 06:29:45 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2M6TjDr015022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Mar 2015 06:29:45 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sun, 22 Mar 2015 01:29:45 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: "ops-dir@ietf.org" <ops-dir@ietf.org>
Thread-Topic: ops review of draft-ietf-tls-sslv3-diediedie
Thread-Index: AQHQZGmWpARkpZLGW0mpB3eKsQYLpw==
Date: Sun, 22 Mar 2015 06:29:44 +0000
Message-ID: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.89.4.20]
Content-Type: multipart/signed; boundary="Apple-Mail=_F33CC1A6-747E-40F3-93F3-037D207CCC16"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8IdPsG08KGBbfyx2U1_Nzib8z9E>
X-Mailman-Approved-At: Sun, 22 Mar 2015 02:39:16 -0700
Cc: "draft-ietf-tls-sslv3-diediedie.all@tools.ietf.org" <draft-ietf-tls-sslv3-diediedie.all@tools.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] ops review of draft-ietf-tls-sslv3-diediedie
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: Sun, 22 Mar 2015 06:29:47 -0000

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.

Summary:

The document, as set forth in its name, makes a specific recommendation regarding SSL v3 and by extension all of its versions: "die die die”. It gives specific reasons for that recommendation, in terms of manifest insecurity, attacks, and general unworthiness of trust.

It also answers a question I have had, which is why TLS didn't naturally replace SSL a long time ago. Specific parameters necessary to that negotiation had not been adequately specified. The document makes an assertion that I understand to be the long-standing consensus of the security community: that any version of TLS is more secure than any version of SSL, and as version numbers increase, TLS itself becomes more secure.

In short, it recommends that implementations that use SSL update to use TLS, and that operators of applications using SSL lean on their vendors or implementors to make the conversion or change to other software packages.

Operational impact:

By implication, administrators of applications need to determine whether their applications are using SSL, and if so upgrade them. The audit is probably most easily accomplished using a web page lookup or email exchange; the specifications for the application will say what they use, and if they have made the conversion, identify in what release they did so. It should then be straightforward for the administrator to determine what version they are running.

One implication that the document doesn’t bring out directly, but which follows from the discussion of the attacks, is that any key or certificate that has been exchanged using SSL may have been compromised via a man-in-the-middle attack, and is therefore suspect. Such certificates and keys should be replaced.

The upgrade process itself may be more painful; the administrator will need to qualify the updated software for his/her use case, and may need to correspond with the vendor or author. This is something administrators generally know how to do, however, so it should not be a blocking issue.

My assessment: The document is clearly written and well argued, and the issues are clearly laid out. It is therefore good to go.