Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiationdetail

"Kemp, David P." <> Tue, 26 January 2010 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1FAA3A67B3; Tue, 26 Jan 2010 07:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tA2FwpF2PrE4; Tue, 26 Jan 2010 07:30:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9A3AC3A6774; Tue, 26 Jan 2010 07:30:51 -0800 (PST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 26 Jan 2010 10:30:20 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [TLS] Confirming consensus about one draft-ietf-tls-renegotiationdetail
thread-index: AcqeZGsopZGN9hXbTp+VH8GNHSiFbwANjDYw
References: <>
From: "Kemp, David P." <>
To: <>, <>
X-OriginalArrivalTime: 26 Jan 2010 15:31:35.0609 (UTC) FILETIME=[A522D290:01CA9E9C]
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiationdetail
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jan 2010 15:30:52 -0000

I confirm that I support publishing Version -03 as-is.


Version -01 states that the semantics of SCSV is identical to the
semantics an empty RI, namely: "this client is capable of supporting
secure renegotiation, and this ClientHello message is an initial
handshake, not a renegotiation handshake."

Version -03 confirms that semantic equivalence and transforms it into
testable processing requirements.  If there were a change to the
processing logic to permit SCSV in renegotiations, the semantics would
"This ClientHello is both an initial handshake (SCSV) and a
renegotiation handshake (non-empty RI)", which is clearly absurd.

I prefer the semantics of Version -01 and Version -03 over making up a
different semantics (SCSV is not equivalent to an empty RI) at this
stage of the game.


-----Original Message-----
From: [] On Behalf Of
Sent: Tuesday, January 26, 2010 3:49 AM
Subject: [TLS] Confirming consensus about one

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 

   (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

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,
IETF Security Area Director

TLS mailing list