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

"Rex, Martin" <martin.rex@sap.com> Tue, 26 January 2010 17:00 UTC

Return-Path: <martin.rex@sap.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 C135C3A67F4 for <tls@core3.amsl.com>; Tue, 26 Jan 2010 09:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.199
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt3DGAllHLWn for <tls@core3.amsl.com>; Tue, 26 Jan 2010 09:00:32 -0800 (PST)
Received: from smtpgw.sap-ag.de (smtpgw02.sap-ag.de [155.56.66.97]) by core3.amsl.com (Postfix) with ESMTP id 4433A3A686C for <tls@ietf.org>; Tue, 26 Jan 2010 09:00:31 -0800 (PST)
From: "Rex, Martin" <martin.rex@sap.com>
To: "tls@ietf.org" <tls@ietf.org>
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: <D28848FB278CE54FB6A302F413ECF7300592698471@DEWDFECCR07.wdf.sap.corp>
References: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: de-DE
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
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
X-BeenThere: tls@ietf.org
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." <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 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

http://tools.ietf.org/rfcdiff

-03 document  http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03
my suggesstions ftp://ftp.sap.com/pub/ietf-work/tls/draft-ietf-tls-renegotiation-04-suggestions-2.txt

Differences:

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-tls-renegotiation-03.txt&url2=ftp://ftp.sap.com/pub/ietf-work/tls/draft-ietf-tls-renegotiation-04-suggestions-2.txt

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.

http://tools.ietf.org/html/rfc2026#section-4.1.1


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.

http://tools.ietf.org/html/rfc4677#section-5.2

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


-Martin


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).
 http://www.ietf.org/mail-archive/web/tls/current/msg04571.html

prompting me to commit on publishing my I-D on Monday 23rd
 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg04576.html

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

 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg04234.html
                http://www.ietf.org/mail-archive/web/tls/current/msg04791.html

 Nasko Oskov    http://www.ietf.org/mail-archive/web/tls/current/msg04590.html
 Wan-Teh Chang  http://www.ietf.org/mail-archive/web/tls/current/msg04585.html
 Mike D'Errico  http://www.ietf.org/mail-archive/web/tls/current/msg04594.html
 Peter Gutmann  http://www.ietf.org/mail-archive/web/tls/current/msg04651.html
 Yoav Nir       http://www.ietf.org/mail-archive/web/tls/current/msg04746.html
 Stefan S.      http://www.ietf.org/mail-archive/web/tls/current/msg04747.html
 Marsh Ray      http://www.ietf.org/mail-archive/web/tls/current/msg04790.html
 David-Sarah H. http://www.ietf.org/mail-archive/web/tls/current/msg04827.html

23-Nov Pasi Eronen (not wearing any hat) on the correct/resonable SCSV in -00
 Pasi Eronen    http://www.ietf.org/mail-archive/web/tls/current/msg04667.html

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

 Florian Weimer http://www.ietf.org/mail-archive/web/tls/current/msg04599.html
 Stephen Henson http://www.ietf.org/mail-archive/web/tls/current/msg04207.html
                http://www.ietf.org/mail-archive/web/tls/current/msg04601.html
 Simon J.       http://www.ietf.org/mail-archive/web/tls/current/msg04665.html
 Kyle Hamilton  http://www.ietf.org/mail-archive/web/tls/current/msg04727.html
 Eric Rescorla  http://www.ietf.org/mail-archive/web/tls/current/msg04794.html
                http://www.ietf.org/mail-archive/web/tls/current/msg04798.html


Objects to SCSV in general:

 Robert Relyea  http://www.ietf.org/mail-archive/web/tls/current/msg04794.html
 Geoffrey K.    http://www.ietf.org/mail-archive/web/tls/current/msg04946.html


The first version of my I-D is quite confusing

23-Nov-2009  draft-mrex-tls-secure-renegotiation-00
 http://www.ietf.org/mail-archive/web/tls/current/msg04674.html


25-Nov-2009  cleanup  draft-mrex-tls-secure-renegotiation-01
 http://www.ietf.org/mail-archive/web/tls/current/msg04817.html


Proposal to entirely substitute "empty RI" in initial ClientHello
                                         with TLS_RENEGO_PROTECTION_REQUEST
 Eric Rescorla  http://www.ietf.org/mail-archive/web/tls/current/msg04794.html

well appreciated:
 Stefan S.      http://www.ietf.org/mail-archive/web/tls/current/msg04797.html
 Stephen H.     http://www.ietf.org/mail-archive/web/tls/current/msg04799.html
 Peter Robinson http://www.ietf.org/mail-archive/web/tls/current/msg04818.html

acceptable:
 AD Pasi Eronen http://www.ietf.org/mail-archive/web/tls/current/msg04834.html
 Yngve P.       http://www.ietf.org/mail-archive/web/tls/current/msg04812.html

could live with it, but would like it to be limited to SSLv3:
 Robert Relyea  http://www.ietf.org/mail-archive/web/tls/current/msg04803.html


Eric annouces this change for the next document update:
 Eric Rescorla  http://www.ietf.org/mail-archive/web/tls/current/msg04848.html

===================================
= draft-ietf-tls-renegotiation-01 =
===================================

26-Nov-2009  draft-ietf-tls-renegotiation-01.txt
 http://www.ietf.org/mail-archive/web/tls/current/msg04847.html

 http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01#section-4


3 Surprises in Document update:

  1.) Eric adopts the label "TLS_RENEGO_PROTECTION_REQUEST" from
      draft-mrex-tls-secure-renegotiation-01

  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.      http://www.ietf.org/mail-archive/web/tls/current/msg04855.html


Chris Newman calls for action to kill interop with extensions-intolerant
Server (SSLv3 and TLS), Nelson Bolyard joins in:
 Chris Newman   http://www.ietf.org/mail-archive/web/tls/current/msg04856.html
 Nelson Bolyard http://www.ietf.org/mail-archive/web/tls/current/msg04886.html


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

27-Nov-2009 IETF Last Call requested for -01 document by AD (Pasi)
 http://www.ietf.org/mail-archive/web/tls/current/msg04928.html

to which some WG participants immediately respond that IETF last call
is premature:
 Stefan S.      http://www.ietf.org/mail-archive/web/tls/current/msg04931.html
                http://www.ietf.org/mail-archive/web/tls/current/msg04961.html
 David-Sarah    http://www.ietf.org/mail-archive/web/tls/current/msg04934.html
 Yoav Nir       http://www.ietf.org/mail-archive/web/tls/current/msg05009.html

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.     (http://www.ietf.org/mail-archive/web/tls/current/msg04855.html)
                http://www.ietf.org/mail-archive/web/tls/current/msg04904.html
                http://www.ietf.org/mail-archive/web/tls/current/msg04991.html

   "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
them.


30-Nov-2009 Official IETF Last Call announcement:
 http://www.ietf.org/mail-archive/web/tls/current/msg04962.html

Further WG discussion questioning the changed SCSV semantics in -01

1) quotes -01 text, makes no clear argument
 Ben Laurie     http://www.ietf.org/mail-archive/web/tls/current/msg04955.html

2) questions "either SCSV or empty RI" for initial ClientHello
   and prefers to allow both, but dislikes MUST send SCSV
 Marsh Ray      http://www.ietf.org/mail-archive/web/tls/current/msg04963.html
                http://www.ietf.org/mail-archive/web/tls/current/msg04980.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05032.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05042.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05050.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05058.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05096.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05179.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05257.html

3) asking for "either one or the other or both" and
   for consistent presence of SCSV for initial and renegotiation ClientHello
 Kyle Hamilton  http://www.ietf.org/mail-archive/web/tls/current/msg04974.html

4) rather remove SCSV entirely than undecisive "either SCSV or empty RI"
 Stephen F.     http://www.ietf.org/mail-archive/web/tls/current/msg05010.html

5) indication that he considers the exact semantics a matter of taste
 Eric Rescorla  http://www.ietf.org/mail-archive/web/tls/current/msg05048.html

6) clear technical(!) preference for easy&clean SCSV semantics
 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg05030.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05302.html
 Mike D'Errico  http://www.ietf.org/mail-archive/web/tls/current/msg05049.html
 David-Sarah H. http://www.ietf.org/mail-archive/web/tls/current/msg05071.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05085.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05273.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05305.html
 Mick Gray      http://www.ietf.org/mail-archive/web/tls/current/msg05080.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05169.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05263.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05303.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05306.html
 James Manger   http://www.ietf.org/mail-archive/web/tls/current/msg05246.html
 Dieter Bratko  http://www.ietf.org/mail-archive/web/tls/current/msg05247.html
 Yoav Nir       http://www.ietf.org/mail-archive/web/tls/current/msg05180.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05248.html


7) firmly against "MUST send SCSV" and confirming "either SCSV or empty RI"
 Chris Newman   http://www.ietf.org/mail-archive/web/tls/current/msg05033.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05041.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05170.html
   or dropping SCSV entirely:
                http://www.ietf.org/mail-archive/web/tls/current/msg05087.html

8) firmly against "MUST send SCSV", but OK with sending both
 Robert Relya   http://www.ietf.org/mail-archive/web/tls/current/msg05264.html
 Nelson Bolyard http://www.ietf.org/mail-archive/web/tls/current/msg05066.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05076.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05181.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05266.html

9) likes to send both SCSV+RI on initial ClientHello
 Stephen Henson http://www.ietf.org/mail-archive/web/tls/current/msg05220.html


10) Eric trying to close some of the issues under discussion
 Eric Rescorla  http://www.ietf.org/mail-archive/web/tls/current/msg05196.html
    SCSV (MCSV)-related feedback to this:
 Michael Gray   http://www.ietf.org/mail-archive/web/tls/current/msg05227.html

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.       http://www.ietf.org/mail-archive/web/tls/current/msg05296.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05309.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05313.html

**************************
* IETF Last Call summary *
**************************


16-Dec-2009  IETF Last Call Summary by Pasi Eronen:
 Pasi Eronen    http://www.ietf.org/mail-archive/web/tls/current/msg05357.html


Discontent with process-related issues:
 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg05373.html
 Nico Williams  http://www.ietf.org/mail-archive/web/tls/current/msg05377.html

AD reply:
 Pasi Eronen    http://www.ietf.org/mail-archive/web/tls/current/msg05394.html


Discussion about SCSV semantics contine:

Pro sensible SCSV semantics:
 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg05359.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05365.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05372.html
 Mike D'Errico  http://www.ietf.org/mail-archive/web/tls/current/msg05364.html
 Kyle Hamilton  http://www.ietf.org/mail-archive/web/tls/current/msg05415.html


Explicitly allow both (SCSV and RI) on initial ClientHello:
 David Kemp     http://www.ietf.org/mail-archive/web/tls/current/msg05370.html



Lengthy Email exchange with a particular point about MCSV semantics and
proposed new text for the upcoming document update (-02, after LastCall):
 Marsh Ray      http://www.ietf.org/mail-archive/web/tls/current/msg05261.html
 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg05265.html
 Marsh Ray      http://www.ietf.org/mail-archive/web/tls/current/msg05366.html
 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg05379.html

Other squabbles about the use of terminology:
 Marsh Ray      http://www.ietf.org/mail-archive/web/tls/current/msg05361.html


===================================
= draft-ietf-tls-renegotiation-02 =
===================================


16-Dec-2009  draft-ietf-tls-renegotiation-02.txt
 http://www.ietf.org/mail-archive/web/tls/current/msg05378.html


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

Relaxed sensible SCSV semantics (MAY everywhere, no MUSTs, not MUST NOTs):
 Mike D'Errico  http://www.ietf.org/mail-archive/web/tls/current/msg05398.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05449.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05456.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05464.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05496.html
 Robert Dugal   http://www.ietf.org/mail-archive/web/tls/current/msg05441.html
 _myself_       http://www.ietf.org/mail-archive/web/tls/current/msg05452.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05498.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05458.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05466.html
 Eric Rescorla  http://www.ietf.org/mail-archive/web/tls/current/msg05445.html
 Uri Blumenthal http://www.ietf.org/mail-archive/web/tls/current/msg05472.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05493.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05519.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05546.html
 Pasi Eronen    http://www.ietf.org/mail-archive/web/tls/current/msg05490.html
 Yoav Nir       http://www.ietf.org/mail-archive/web/tls/current/msg05491.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05521.html
 Stephen Henson http://www.ietf.org/mail-archive/web/tls/current/msg05497.html
 Marsh Ray      http://www.ietf.org/mail-archive/web/tls/current/msg05500.html
                http://www.ietf.org/mail-archive/web/tls/current/msg05511.html
 Nasko Oskov    http://www.ietf.org/mail-archive/web/tls/current/msg05501.html

 Nelson Bolyard http://www.ietf.org/mail-archive/web/tls/current/msg05559.html


===================================
= draft-ietf-tls-renegotiation-03 =
===================================

05-Jan-2010  draft-ietf-tls-renegotiation-03.txt
 http://www.ietf.org/mail-archive/web/tls/current/msg05560.html

07-Jan-2010  Protocol Action: Document approved by IESG
 http://www.ietf.org/mail-archive/web/tls/current/msg05560.html