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

Nikos Mavrogiannopoulos <> Wed, 27 January 2010 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80AB33A68FC; Tue, 26 Jan 2010 23:19:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CPCDQsOeY3Ey; Tue, 26 Jan 2010 23:19:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CA43C3A68B0; Tue, 26 Jan 2010 23:19:41 -0800 (PST)
Received: by pxi16 with SMTP id 16so3858988pxi.29 for <multiple recipients>; Tue, 26 Jan 2010 23:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=QTbZOUCTPvXIz89wpKsti3+fzq1eFFOtOSs5C0WCzH4=; b=re0YLgWI5VFjVovX23yq2/j7hSLRWBRlTTlhY6VP8uyd4dm53xUgan7a9k6W+ppzSe +tIajSzPxN+qlQZyEnh1eKswFvjTUERQxtxNkqABY3c/5R8Itd7QSPSIAVSDs2DL1vnE MzEc2s1ui0bBeYt2kr028FtlQceKAv2aUbHls=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ZoG741JeJFH1urC0XlE4MEKjBBjnEAFINUD8qhzSqTCIuoRVKAnjClUEk7Qp5QrybS eoMWMcE7pw6EjMzhlW9+caKk84ukPFJrpBvTY/WXOj9dQtH0Drs6V8kvxkmHR9NQgJ8v FDh0HzGh6ik8QcnpJucheG3WXGRAq51Ahmm3I=
MIME-Version: 1.0
Received: by with SMTP id k26mr584786wae.186.1264576791298; Tue, 26 Jan 2010 23:19:51 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Wed, 27 Jan 2010 08:19:51 +0100
X-Google-Sender-Auth: 77355ffe5acf4938
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
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: Wed, 27 Jan 2010 07:19:45 -0000

Concerning the SCSV behavior I prefer publishing the specification as-is.


On Tue, Jan 26, 2010 at 9:49 AM,  <> wrote:
> 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