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

"Rex, Martin" <> Tue, 26 January 2010 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C135C3A67F4 for <>; Tue, 26 Jan 2010 09:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.199
X-Spam-Status: No, score=-9.199 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tt3DGAllHLWn for <>; Tue, 26 Jan 2010 09:00:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4433A3A686C for <>; Tue, 26 Jan 2010 09:00:31 -0800 (PST)
From: "Rex, Martin" <>
To: "" <>
Date: Tue, 26 Jan 2010 18:00:31 +0100
Thread-Topic: Confirming consensus about one draft-ietf-tls-renegotiation detail
Thread-Index: AcqeZGsopZGN9hXbTp+VH8GNHSiFbwAK55bg
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: de-DE
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 26 Jan 2010 17:00:34 -0000

(resent without attachment)

Dear TLS,

I have raised concerns to a few changes in the -03 document
that went totally unreviewd, and to issues of SCSV semantics
(the addition of two explicit MUST NOTs) that do not reflect
WG consensus.

I did not and do not want to "reopen" discussion!
(I explictly urged Pasi to get the SCSV semantics clarified
 on Dec-16th, but unfortunately, he declined to touch this
 issue in any way.  Which is bad because there exist no two
 documents of the draft with the same semantics).

I also think there are significant editorial (concerning
comprehensiveness) issues with sections that were newly
added to -03 and approved without any kind of review.

For simplicity, I have provided my _suggestions_ to fix
these issues in form of an updated draft document.

For ease of access and comparision, you can look at
the differences with the IETF tools

-03 document
my suggesstions


Attached is a suggestion for a document change that
would resolve my concerns (technically and editorial)

During all the WG discussion I was disappointed about
the mediocre document quality of the WG document.
The final -03 document is the first document that comes
close to the expection that the IETF has for a proposal
targeting Proposed Standard.

The installed base of (apps using) TLS is in the
ballpark of one billion.  The optimistic hope of the
TLS WG is that we get this patch adopteb by 50% in the
first 6 month, and around 80% in 12 month.

That is an optimistic goal, and considering the normal
"progress" of IETF proposed standards, the "adoption"
we are looking at is something that normally applies
to "draft standards", not "proposed standards".

In addition to that, I assume there exist >100 independent
implementations of TLS, and only a small fraction of
the implementors (1/4 maybe) is actively participating
the IETF.  So it would be good if the document was readable
especially for those, who have the task of implementing
this update still ahead of them.

In the spirit of "The Tao of IETF", I have compiled
a list of relevant discussion of the WG concerning
specific SCSV semantics from "those who cared" when
it was discussed.

and I didn't find a consensus for the two MUST NOTs
that unexplicably popped up in the -03 document.


Here is a WG summery I compiled from my personal EMail
archive.  I believe it to contain all relevant postings
(I searched for keywords "cipher" and "MCSV").
I would appreciate pointers to significant postings
that I may have missed (persons I've missed or
different/new technical aspects I've missed):

* WG Consensus Call on draft-ietf-tls-renegotiation-00 *

20-Nov-2009 -- Working group consensus call based on the -00 document
(containing a brief description of resonable SCSV semantics).

prompting me to commit on publishing my I-D on Monday 23rd

Support for reasonable/simpler SCSV "I'm updated" semantics during
the WG consensus call:


 Nasko Oskov
 Wan-Teh Chang
 Mike D'Errico
 Peter Gutmann
 Yoav Nir
 Stefan S.
 Marsh Ray
 David-Sarah H.

23-Nov Pasi Eronen (not wearing any hat) on the correct/resonable SCSV in -00
 Pasi Eronen

Confirmation of adding SCSV (no explicit or clear semantics expressed):

 Florian Weimer
 Stephen Henson
 Simon J.
 Kyle Hamilton
 Eric Rescorla

Objects to SCSV in general:

 Robert Relyea
 Geoffrey K.

The first version of my I-D is quite confusing

23-Nov-2009  draft-mrex-tls-secure-renegotiation-00

25-Nov-2009  cleanup  draft-mrex-tls-secure-renegotiation-01

Proposal to entirely substitute "empty RI" in initial ClientHello
                                         with TLS_RENEGO_PROTECTION_REQUEST
 Eric Rescorla

well appreciated:
 Stefan S.
 Stephen H.
 Peter Robinson

 AD Pasi Eronen
 Yngve P.

could live with it, but would like it to be limited to SSLv3:
 Robert Relyea

Eric annouces this change for the next document update:
 Eric Rescorla

= draft-ietf-tls-renegotiation-01 =

26-Nov-2009  draft-ietf-tls-renegotiation-01.txt

3 Surprises in Document update:

  1.) Eric adopts the label "TLS_RENEGO_PROTECTION_REQUEST" from

  2.) -01 changes SCSV semantics quite different from what was
      discussed.  Instead of obsoleting empty RI on initial ClientHello,
      there is now an "either empty RI" or "SCSV".

  3.) for renegotiation ClientHello, the document says
      "only renegotiation_info" may be used.

      The RI architecture requires that the verify_data is sent
      from Client to Server for renegotiation, which makes it obvious
      that the use of SCSV (alone) is insufficient.

   This wording, however, is *NOT* equivalent to "MUST NOT include"
   and in particular *NOT* equivalent to a requirement for the
   Server "MUST abort if both are present".

The unexpected (2) change prompts disagreement:
 Stefan S.

Chris Newman calls for action to kill interop with extensions-intolerant
Server (SSLv3 and TLS), Nelson Bolyard joins in:
 Chris Newman
 Nelson Bolyard

* IETF Last Call requested on draft-ietf-tls-renegotiation-01 *

27-Nov-2009 IETF Last Call requested for -01 document by AD (Pasi)

to which some WG participants immediately respond that IETF last call
is premature:
 Stefan S.
 Yoav Nir

I did _not_ complain about the early IETF last call (assuming that
it was possible to get the document fixed before the spec was finalized).

The IETF Last Call was only about the document in general, it was
definitely not meant to confirm specific details on semantics,
e.g. like the exact SCSV semantics.

Even though Stefan Santesson has helped me authoring
draft-mrex-tls-secure-renegotiation and did complain that the -01 WG I-D
provides two different signals on initial ClientHellio in disagreement
to what was discussed, he does not distinguish this semantics
detail in the further discussion, because the IETF Last Call is
made to confirm whether or not using RI, and not about details
of the RI document (of which there are little anyway).

 Stefan S.     (

   "Both proposals agree on the same initial signaling (cipher suite
    for C->S and empty RI for S->C)"

The use of the same label "TLS_RENEGO_PROTECTION_REQUEST" but different
semantics makes it quite difficult for the discussion to differentiate

30-Nov-2009 Official IETF Last Call announcement:

Further WG discussion questioning the changed SCSV semantics in -01

1) quotes -01 text, makes no clear argument
 Ben Laurie

2) questions "either SCSV or empty RI" for initial ClientHello
   and prefers to allow both, but dislikes MUST send SCSV
 Marsh Ray

3) asking for "either one or the other or both" and
   for consistent presence of SCSV for initial and renegotiation ClientHello
 Kyle Hamilton

4) rather remove SCSV entirely than undecisive "either SCSV or empty RI"
 Stephen F.

5) indication that he considers the exact semantics a matter of taste
 Eric Rescorla

6) clear technical(!) preference for easy&clean SCSV semantics
 Mike D'Errico
 David-Sarah H.
 Mick Gray
 James Manger
 Dieter Bratko
 Yoav Nir

7) firmly against "MUST send SCSV" and confirming "either SCSV or empty RI"
 Chris Newman
   or dropping SCSV entirely:

8) firmly against "MUST send SCSV", but OK with sending both
 Robert Relya
 Nelson Bolyard

9) likes to send both SCSV+RI on initial ClientHello
 Stephen Henson

10) Eric trying to close some of the issues under discussion
 Eric Rescorla
    SCSV (MCSV)-related feedback to this:
 Michael Gray

11) suggests spec to be explicit, prefer use of SCSV only for applicable
    initial client hellos, OK with MAY send SCSV in every handshake,
    could live with MUST use SCSV in every initial ClientHello
 Yngve P.

* IETF Last Call summary *

16-Dec-2009  IETF Last Call Summary by Pasi Eronen:
 Pasi Eronen

Discontent with process-related issues:
 Nico Williams

AD reply:
 Pasi Eronen

Discussion about SCSV semantics contine:

Pro sensible SCSV semantics:
 Mike D'Errico
 Kyle Hamilton

Explicitly allow both (SCSV and RI) on initial ClientHello:
 David Kemp

Lengthy Email exchange with a particular point about MCSV semantics and
proposed new text for the upcoming document update (-02, after LastCall):
 Marsh Ray
 Marsh Ray

Other squabbles about the use of terminology:
 Marsh Ray

= draft-ietf-tls-renegotiation-02 =

16-Dec-2009  draft-ietf-tls-renegotiation-02.txt

* Further WG discussions about SCSV semantics, converging to consensus *

Relaxed sensible SCSV semantics (MAY everywhere, no MUSTs, not MUST NOTs):
 Mike D'Errico
 Robert Dugal
 Eric Rescorla
 Uri Blumenthal
 Pasi Eronen
 Yoav Nir
 Stephen Henson
 Marsh Ray
 Nasko Oskov

 Nelson Bolyard

= draft-ietf-tls-renegotiation-03 =

05-Jan-2010  draft-ietf-tls-renegotiation-03.txt

07-Jan-2010  Protocol Action: Document approved by IESG