Last Call Review of draft-ietf-tls-sslv3-diediedie-02
review-ietf-tls-sslv3-diediedie-02-opsdir-lc-baker-2015-03-28-00

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.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail