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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 22 March 2015 12:43 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 C0B611A9098; Sun, 22 Mar 2015 05:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 UMc3CWvpXn87; Sun, 22 Mar 2015 05:43:45 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4891B1A9096; Sun, 22 Mar 2015 05:43:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19E4EBECC; Sun, 22 Mar 2015 12:43:44 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFZje8fMINNq; Sun, 22 Mar 2015 12:43:43 +0000 (GMT)
Received: from [31.133.142.144] (dhcp-8e90.meeting.ietf.org [31.133.142.144]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 38C38BEC0; Sun, 22 Mar 2015 12:43:42 +0000 (GMT)
Message-ID: <550EB8F2.10203@cs.tcd.ie>
Date: Sun, 22 Mar 2015 12:43:30 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
References: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com>
In-Reply-To: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="OQCFxgrnN3HpwJBLXuqxQiMhtKDsEMnaI"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/L4CyBU4IaLmSgjCCgc7yrW-A7J0>
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: Re: [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 12:43:46 -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.