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

This message is raising separate issues than the consensus call, please
conduct any discussion of this message on a separate thread with a
different subject line.  

Thanks,

Joe

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Rex,
> Martin
> Sent: Tuesday, January 26, 2010 9:01 AM
> To: tls@ietf.org
> Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-
> renegotiation detail
> 
> (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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls