[TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
<Pasi.Eronen@nokia.com> Tue, 26 January 2010 08:49 UTC
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8D13A6810; Tue, 26 Jan 2010 00:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.989
X-Spam-Level:
X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bToYrXIufRzH; Tue, 26 Jan 2010 00:49:27 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id B4E3F3A67B0; Tue, 26 Jan 2010 00:49:26 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0Q8n8El010149; Tue, 26 Jan 2010 10:49:33 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 10:49:26 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 10:49:17 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 26 Jan 2010 09:49:07 +0100
From: Pasi.Eronen@nokia.com
To: ietf@ietf.org, tls@ietf.org
Date: Tue, 26 Jan 2010 09:49:06 +0100
Thread-Topic: Confirming consensus about one draft-ietf-tls-renegotiation detail
Thread-Index: AcqeZGsopZGN9hXbTp+VH8GNHSiFbw==
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jan 2010 08:49:17.0508 (UTC) FILETIME=[71B4E840:01CA9E64]
X-Nokia-AV: Clean
Subject: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: tls@ietf.org
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/listinfo/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: Tue, 26 Jan 2010 08:49:28 -0000
Concerns have been raised that the IESG may have judged community consensus about one specific detail of draft-ietf-tls-renegotiation prematurely. In particular, the discussion that happened just after the IETF Last Call ended might have caused some people to change their opinion, and also the holiday season may have delayed replies. To eliminate doubt about the situation, and allow the RFC to come out as soon as possible, we have decided to confirm the community consensus about this detail. The detail in question is whether the "Signalling Cipher Suite Value" (SCSV) can be included when performing secure renegotiation (in addition to the renegotiation_info extension). Currently, the SCSV is not included. In the version that went to IETF Last Call (version -01), the relevant text was: "This cipher suite has exactly the same semantics as an empty "renegotiation_info" extension. [..] Because this cipher suite is equivalent to an empty "renegotiation_info" extension, only "renegotiation_info" may be used rehandshakes." (in Section 4) Version -03 (the latest version) has rephrased the text as follows: "The SCSV MUST NOT be included." (in Section 3.5, "Client Behavior: Secure Renegotiation") "When ClientHello is received, the server MUST verify that it does not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV. If the SCSV is present, the server MUST abort the handshake." (in Section 3.7, "Server Behavior: Secure Renegotiation") It has been suggested that recent discussions may have changed the consensus, and some people have proposed changing this so that including the SCSV in secure renegotiation ClientHellos is allowed (but not required), and rephrasing the text that says SCSV, when received, is treated the same as an empty renegotiation_info extension (which means "not renegotiation"). Note that this text applies to secure renegotiation ClientHellos. Other possible changes to the details concerning the SCSV (such as requiring it in all ClientHellos) were suggested during the IETF Last Call, but are explicitly outside the scope of this email. According to our notes, at least the following individuals seem to have expressed support for publishing version 01/02/03 (without making further changes to the details concerning the SCSV): Adrian Farrel Alexey Melnikov Ben Laurie Bodo Moeller Chris Newman Cullen Jennings Dan Romascanu David P. Kemp Eric Rescorla Geoffrey Keating Glen Zorn Jari Arkko Lars Eggert Lisa Dusseault Magnus Westerlund Nicolas Williams Pasi Eronen Peter Robinson Ralph Droms Rob P. Williams Robert Relya Robert Sparks Ron Bonica Stephen Farrell Steve Checkoaway Steve Dispensa Tim Polk Uri Blumenthal The following individuals seems to have expressed a preference for *not* publishing this document until the details concerning the SCSV are changed as described above: Marsh Ray Martin Rex Michael D'Errico Nasko Oskov Robert Dugal Stephen Henson Yoav Nir A number of other people also sent comments during the IETF Last Call (possibly proposing other changes to the details concerning the SCSV), but did not clearly fall into either list above. If the recent discussions have caused you to change your mind (or we have interpreted your preference incorrectly, or you were not on either list), please send an email to the TLS WG mailing list by Tuesday February 2nd. In your reply, please include one of the following: (1) I prefer publishing the specification as-is. (2) I prefer *NOT* publishing the specification as-is, and instead prefer changing the text so that including the SCSV in secure renegotiation ClientHellos is allowed (but not required). Unless a significant amount of additional people believe that making this change if preferable over publishing the spec now, the IESG expects to have the RFC out soon after February 2nd. So we hope this consensus confirmation does not delay the RFC, or deployment of its implementations. Note that this is not a general call to revisit other details of draft-ietf-tls-renegotiation, or propose additional changes. If you absolutely wish to have other discussions related to the draft, we respectfully ask you to change the subject line. Best regards, Pasi IETF Security Area Director
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- [TLS] Confirming consensus about one draft-ietf-t… Pasi.Eronen
- Re: [TLS] Confirming consensus about one draft-ie… Robert Dugal
- Re: [TLS] Confirming consensus about one draft-ie… Dr Stephen Henson
- Re: [TLS] Confirming consensus about one draft-ie… Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Michael D'Errico
- Re: [TLS] Confirming consensus about one draft-ie… Rex, Martin
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- [TLS] Metadiscussion on changes in draft-ietf-tls… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Marsh Ray
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Hovav Shacham
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Confirming consensus about one draft-ie… Yngve Nysaeter Pettersen
- [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Nelson B Bolyard
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Bob Braden
- Re: [TLS] Confirming consensus about one Michael D'Errico
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Marsh Ray
- Re: [TLS] Confirming consensus about one draft-ie… Robert Relyea
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Paul Hoffman
- [TLS] interoperability and security guarantees [w… Daniel Kahn Gillmor
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Michael D'Errico
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Nikos Mavrogiannopoulos
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Bill Frantz
- Re: [TLS] Confirming consensus about one draft-ie… tom.petch
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)