Re: [TLS] [OPS-DIR] ops review of draft-ietf-tls-sslv3-diediedie

joel jaeggli <> Sun, 22 March 2015 12:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E53C1A908E; Sun, 22 Mar 2015 05:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4T0CZ727gizx; Sun, 22 Mar 2015 05:30:45 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B862E1A908F; Sun, 22 Mar 2015 05:30:45 -0700 (PDT)
Received: from mb-aye.local ( []) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id t2MCUfm8001322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 22 Mar 2015 12:30:42 GMT (envelope-from
To: "Fred Baker (fred)" <>, "" <>
references: <>
From: joel jaeggli <>
message-id: <>
Date: Sun, 22 Mar 2015 07:30:35 -0500
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0
mime-version: 1.0
in-reply-to: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIsibiwWufo32VcwfHxMm931Ts0soeBkf"
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [TLS] [OPS-DIR] ops review of draft-ietf-tls-sslv3-diediedie
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Mar 2015 12:30:47 -0000

Thanks fred!


On 3/22/15 1:29 AM, Fred Baker (fred) wrote:
> 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.
> _______________________________________________
> OPS-DIR mailing list