RE: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Wed, 03 February 2010 18:59 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E1128C1DE; Wed, 3 Feb 2010 10:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 I2FFUAwQy0CR; Wed, 3 Feb 2010 10:59:39 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0BB3628C1DD; Wed, 3 Feb 2010 10:36:59 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAM9RaUurRN+K/2dsb2JhbADBEpgSgkWCAAQ
X-IronPort-AV: E=Sophos;i="4.49,399,1262563200"; d="scan'208";a="145156033"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2010 18:37:30 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o13IbUN9026752; Wed, 3 Feb 2010 18:37:30 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 10:37:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
Date: Wed, 03 Feb 2010 10:37:28 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50990EFB5@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
Thread-Index: AcqeZGsopZGN9hXbTp+VH8GNHSiFbwGmh4Ig
References: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: tls@ietf.org, ietf@ietf.org
X-OriginalArrivalTime: 03 Feb 2010 18:37:30.0239 (UTC) FILETIME=[F11E48F0:01CAA4FF]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 18:59:40 -0000

The deadline for providing additional information was yesterday.

The results very clearly show that the course of action preferred by the
community is publishing the document without making further changes to
the details concerning the SCSV.

Cheers,
Joe
TLS Working group co-chair

According to our notes, at least the following individuals 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
Bill Frantz
Bodo Moeller
Chris Newman
Cullen Jennings
Dan Romascanu
David P. Kemp
Eric Rescorla
Geoffrey Keating
Glen Zorn
Hovav Shacham
Jari Arkko
Lars Eggert
Lisa Dusseault
Magnus Westerlund
Marsh Ray
Michael D'Errico
Nasko Oskov
Nicolas Williams
Nikos Mavrogiannopoulos
Pasi Eronen
Peter Robinson
Ralph Droms
Rob Dugal
Rob P. Williams
Robert Relya
Robert Sparks
Ron Bonica
Stephen Farrell
Stephen Henson
Steve Checkoaway
Steve Dispensa
Tim Polk
Uri Blumenthal
Yngve Nysaeter Pettersen

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:

Martin Rex
Tom Petch
Yoav Nir

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Pasi.Eronen@nokia.com
> Sent: Tuesday, January 26, 2010 12:49 AM
> To: ietf@ietf.org; tls@ietf.org
> Subject: [TLS] Confirming consensus about one draft-ietf-tls-
> renegotiationdetail
> 
> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls