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

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 22 Mar 2015 06:29:44 +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.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 22 Mar 2015 07:30:35 -0500

Thanks fred!

joel

On 3/22/15 1:29 AM, Fred Baker (fred) wrote:
> _______________________________________________
> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Mar 2015 12:43:30 +0000

Thanks Fred for the thoughtful review.

I think one thing is worth double-checking. You said:

On 22/03/15 06:29, Fred Baker (fred) wrote:
> 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

I don't think that is the case, as SSL's imperfections bad as they
are, don't expose long-term (private) keying material. But it is
worth checking. Short-term keys will naturally be replaced without
any operator action in any SSL->TLS transition I think. And any
trust anchors that were accepted via self-signed certificates will
be as good or bad as ever and are probably best left alone if one
isn't changing s/w but just a config.

So I don't see an operator action here that we ought document in
this draft. But if there were things operators ought do, that are
not purely implementation specific issues, then I think those'd be
worth noting in the document, so this is just to check that. If
someone knows of such, please send text and the WG can process
that.

As the relevant AD, I'll interpret silence here as "no change
needed."

Cheers,
S.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 22 Mar 2015 06:57:07 -0700

On 22 March 2015 at 06:01, Fred Baker (fred) <[email-masked]> wrote:
>> On Mar 22, 2015, at 7:43 AM, Stephen Farrell <[email-masked]> wrote:
> You may ell be correct. I also noted, after having sent the email, that it is fairly probable that a different crypto algorithm might be selected as a result of the transition, which would entail obtaining relevant keys and certificates anyway.

Hi Fred,

Thanks for the writeup.

With respect to this issue, I just did some double-checking and the
treatment of certificates and the associated long-term keying material
is identical between SSL3 and TLS 1.1.  Some changes were made with
respect to signatures in TLS 1.2, but those probably won't materially
affect the analysis.

So, absent new attacks being found, my analysis is that we're OK with
respect to long-term keying material.  If someone does find an attack,
then we'll be retiring TLS 1.0 and 1.1 in a panic.

--Martin

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 22 Mar 2015 13:01:53 +0000

As you say, food for thought.