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