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

From: <[email-masked]>
Date: Tue, 26 Jan 2010 09:49:06 +0100

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

---

From: "Robert Dugal" <[email-masked]>
Date: Tue, 26 Jan 2010 06:01:54 -0500

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
[email-masked]
direct        905.501.3848
fax             905.507.4230
www.certicom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, January 26, 2010 3:49 AM
To: [email-masked]; [email-masked]
Subject: [TLS] Confirming consensus about one draft-ietf-tls-renegotiationdetail

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

Marsh Ray
Martin Rex
Michael D'Errico
Nasko Oskov
Robert Dugal
Stephen Henson
Yoav Nir

  

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 26 Jan 2010 11:57:15 +0000

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 26 Jan 2010 10:30:20 -0500

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

Rationale:

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
be:
"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.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 26, 2010 3:49 AM
To: [email-masked]; [email-masked]
Subject: [TLS] Confirming consensus about one
draft-ietf-tls-renegotiationdetail

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

Marsh Ray
Martin Rex
Michael D'Errico
Nasko Oskov
Robert Dugal
Stephen Henson
Yoav Nir

  

Best regards,
Pasi

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Jan 2010 08:34:09 -0800

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 26 Jan 2010 09:01:06 -0800

I've already changed my code to comply with the MUST NOT send SCSV
and RI in the same hello message, and have my server abort if it
sees both.  So far nobody that has connected to my test server* has
sent both, and there have been lots of connections from a variety
of clients implementing the fix.

Mike

* https://www.mikestoolbox.net

---

From: "Rex, Martin" <[email-masked]>
Date: Tue, 26 Jan 2010 18:00:31 +0100

(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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 26 Jan 2010 09:18:09 -0800

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rex,
> Martin
> Sent: Tuesday, January 26, 2010 9:01 AM
> To: [email-masked]
> Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-
> renegotiation detail
> 
> -03 document
http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03
> renegotiation-04-suggestions-2.txt
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
> 
> 23-Nov Pasi Eronen (not wearing any hat) on the correct/resonable SCSV
in
> -00
> 7) firmly against "MUST send SCSV" and confirming "either SCSV or
empty
> RI"

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jan 2010 18:57:24 +0100 (MET)

>    "Server Behavior: Secure Renegotiation")

http://tools.ietf.org/html/rfc2119#section-6

6. Guidance in the use of these Imperatives^M

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

The two MUST NOTs that popped up in -03 are in violation of rfc2119 section 6!

Keep in mind that sending SCSV on renegotiations is explicitly
permitted by -03 for old renegotiations so that is inconsistent.

Further inconsistencies:  section 3.3 says "the SCSV may be safely be
sent to any server".  which obviously contradicts both new MUST NOTs.

I think we all agree that using a cipher suite value for signaling
is a creative use ("hack") of a TLS protocol extensibility option that
is not documented in this fashion in SSL/TLS.  By doing this, we
should limit the changes of the semantics of this extensibility
option to the absolute necessary.   There never was an interop
problem based on a presence of a particular cipher suite value
in TLS, and it doesn't seem like a good idea to create such
an interop problem for the presence of a cipher suite value
in ClientHello when it is avoidable.  It can be easily avoided
The WG discussion just before XMas developed consensus on
how to do this.

Did anyone of you review the new sections in the -03 draft?

Question to those who are voicing opinions just now, what would
you tell someone who has little TLS experience and just read
the -03 document, to which attack this paragraph in -03
refers (section 4.2, bottom of page 9):
http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03#page-9

and to which "above attack" section 4.3 on page 10 refers?

section 4.2, is not only confusing, it is also inconsistent.

   However, the attack will be detected by the client when the
   server sends an empty "renegotiation_info" extension and the
   client is expecting one containing the previous verify data.

contradicts

   When the ServerHello is received, the client MUST verify that it does
   not contain the "renegotiation_info" extension.  If it does, the
   client MUST abort the handshake.  [Because the server has already
   indicated it does not support secure renegotiation the only way that
   this can happen is if the server is broken or there is an attack.]

I do not think that rushing the document out of the door as-is
would be a good idea.  This would set new lows for the level
of IETF Proposed Standard.

*I* have never suggested and do not endorse the specific
SCSV semantics as described in the -03 document.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Jan 2010 10:15:11 -0800

>The two MUST NOTs that popped up in -03 are in violation of rfc2119 section 6!

...as are about half of all MUSTs and SHOULDs in modern IETF standards.

>Did anyone of you review the new sections in the -03 draft?

Yes.

>of IETF Proposed Standard.

This indicates that you need to read more standards-track RFCs, then.

--Paul Hoffman, Director
--VPN Consortium

---

From: Marsh Ray <[email-masked]>
Date: Tue, 26 Jan 2010 14:07:27 -0600

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jan 2010 21:43:07 +0100 (MET)

> ...as are about half of all MUSTs and SHOULDs in modern IETF standards.

what do you want to say with this?

That implementors should ignore at least half of the MUSTs and SHOULDs
in IETF documents, because they don't make any sense, create unnecessary
interop problems or are otherwise harmful -- and should not be in the
document in the first place?

That may apply to IETF documents where you were involved in the process,
but it did not apply to documents where I was involved ... so far.

The engineer in me is unable to just close his eyes on obvious
problems, in particular when there is an easy fix, I'm sorry.

> >Did anyone of you review the new sections in the -03 draft?

The authors should be interested in the inconsistencies you likely
have encountered while reviewing the -03 draft.

Some aspects are likely more apparent to implementors (one of the
reasons for the IETF "we believe in running code" attitude) -- and to those
who are sufficiently familar with code implementing this part of TLS
to think in terms of actual lines of code, code complexity and testing
effort while reviewing the document.

> This indicates that you need to read more standards-track RFCs, then.

What is your suggestion to improve the situation?

Reading I-Ds during IETF Last Call and providing feedback to the
authors and/or working group might help.  But that requires that
a document is in a resonable shape when it is being Last Called.

draft-ietf-tls-renegotiation-03 is the first version of the
document that is in a shape close to the expectations of 
the IETF for documents targeting Proposed Standard.

There is considerable a considerable of changes in -03 that wasn't
in any prior version of the document, and there are changes to the
semantics (two entirely new MUST NOTs and two unexplained NOT RECOMMEDEDs)
that are _not_ aligned with the WG consensus preceding the -03 document
and they are in conflict with rfc-2119.

Any discussion (let alone consensus) on the changes in the -03 document
was preempted by the IESG approving the document in less than two
days after publication during the holiday season.

I'm not asking for a new change, I'm asking for a _revert_ of a
new change that creates several unnecessary problems.

And I'm asking for an editorial review of the -03 draft, since
some would seriously benefit from editorial corrections.

The IETF used to be a standardization body with an open and fair
process where technical merit, running code, technical objections
and rough consensus of those who cared was more important
than any count of votes.

I don't want to hold up the document.

I did _not_ complain about the premature IETF Last Call because
I was still hoping the document quality issues could be resolved
entirly during WG discussion (there were ~5 complaints).

I _urged_ Pasi to make his consensus call on SCSV semantics on
Dec 16th, when there was still plenty of time considering the
(lack of) document quality at that point.

In order to help on fixing the problems -03, I even provided
an updated document as suggestion for all the issues that
should be fixed before publication.

After all, the target audience of this document is supposed to
be much larger (within a very short time frame) than most other
documents published by the IETF.  Therefore the technical quality
appears to be significant, in spite of the importance of getting
the solution implemented.

-Martin

---

From: Hovav Shacham <[email-masked]>
Date: Tue, 26 Jan 2010 12:52:59 -0800

>   (1) I prefer publishing the specification as-is.

-hs.

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jan 2010 22:43:32 +0100 (MET)

> handshake, not a renegotiation handshake."

But you do realize that we discussed this issue on the WG mailing
list and the I provided an explanation along the lines of a
semi-formal correctness proof that this rationale is based on
a misunderstanding and a poor choice of words in the specification.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 26 Jan 2010 17:50:23 -0500

Yes.  I agree that SCSV could be defined to convey only 1 bit of
information while RI conveys 2 bits, and agree that -01 (which went
through last call) does not define it that way.

What I don't understand is why the issue of changing the semantics of
-01 and -03 to reflect a "1 bit SCSV" is so #$%& important. 
1. It is trivially easy to code to either version.
2. There is no security impact of using either version.
3. It is easier to articulate and to understand an "identical" soundbite
than to explain how SCSV and empty RI are semantically different, and
4. The "identical" version is ready to go, in the form of -03 that can
be published as an RFC right now.

And although I hesitate to bring up the following since they are
non-essential,
5. SCSV is a hack meant to appease ancient and/or non-conforming
servers.  That is one ugly baby, and I wish it would just disappear.
There is absolutely no reason for it ever to be sent in a ClientHello
containing a non-empty RI (it is a no-op that just wastes N bits of
bandwidth to convey 0 bits of additional information, and no legacy
implementation would ever send or interpret it), so I see absolutely no
downside to prohibiting it during renegotiation.
6. Reducing optional elements is always good security hygiene (hash
collision space, covert channels, stack overflow alignment, etc.)  Take
away a useless knob and nobody can twiddle that knob against you.

Dave

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 4:44 PM
To: Kemp, David P.
Cc: [email-masked]; [email-masked]
Subject: Re: [TLS] Confirming consensus about one

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 27 Jan 2010 08:19:51 +0100

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

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Jan 2010 09:56:34 +0200

I've stayed out of this discussion so far, because my opinion has already been noted, but since you've changed the subject...

> 1. It is trivially easy to code to either version.

Actually it's easier to hard-code the ciphersuite list on the client, because it never changes with most applications. Adding logic to differentiate between initial handshakes and repeated handshakes complicates the code (though not by much)

> than to explain how SCSV and empty RI are semantically different, and

"SCSV means the client supports RI". There. That was easy to articulate. An empty extension is less easy IMO.

> be published as an RFC right now.

And this would be very important, if the world was holding its breath waiting for RI. I think it will take several years before RI is really deployed in a useful way, so I don't agree that spending a few more weeks getting it right is wrong because we have to publish this thing "now"

> downside to prohibiting it during renegotiation.

To me RI looks like a hack just as much as SCSV. Hopefully in the future, the way to indicate support for secure renegotiation would be in the client version of the ClientHello.

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Wed, 27 Jan 2010 14:17:41 +0100

I prefer publishing the specification as-is.

Additional comment:

The SCSV is a temporary fallback, one that will not be needed when clients  
enter strict mode, since when that happens servers have to support the RI  
extension.  Its use should therefore be kept to the minimum needed to  
provide the extra security it is designed to provide.

IMO the only situations in which the SCSV should be sent are:

    1) Initial connections when the server is known to not tolerate TLS  
Extensions, or this is not known, and
    2) During renegotiation with a server known not to support the RI  
extension _and_ that does not tolerate TLS Extensions, just in case this  
is a MITM attack and the real server actually supports RI, in which case  
we want the connection shut down. If the server tolerates extensions then  
only the RI extension should be sent.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 27 Jan 2010 09:39:34 -0500

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 

> I've stayed out of this discussion so far, because my opinion has
already
> been noted, but since you've changed the subject...

Actually Martin and I failed to change the subject while changing the
topic.
Sorry.  Fixed.  Ietf list dropped.

> "SCSV means the client supports RI". There. That was easy to
articulate.
> An empty extension is less easy IMO.

"RI means the client supports RI" is less easy?  That doesn't pass the
sniff test.

> And this would be very important, if the world was holding its breath
> waiting for RI. I think it will take several years before RI is really
> deployed in a useful way, so I don't agree that spending a few more
> weeks getting it right is wrong because we have to publish this thing
"now"

Agreed.  As noted earlier, I think -03 has already gotten it right in
terms of normative requirements -- MUST NOTs.  I have no position
on whether informative text should continue to be refined.

> To me RI looks like a hack just as much as SCSV. Hopefully in the
future,
> the way to indicate support for secure renegotiation would be in the
> client version of the ClientHello.

I don't understand.  The essence of negotiation is "client sends
everything
it supports, server responds with the intersection of what it supports."

* Client sending an extension to say it supports that extension is
standard.
* Client sending an extension with no prior context to signal that there
was no prior handshake sounds logical to me.
* Client sending an extension with prior context to signal that there
was
a prior handshake sounds logical to me.

* Client sending a ciphersuite to say it supports an extension, and
server
responding with an extension that was not sent by the client is an
unprecedented exception to a general rule (i.e., a hack).
* Client sending a ciphersuite to say it supports an extension in the
same
message that contains that extension is redundant (i.e., a hack).

Dave

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 16:09:07 +0100 (MET)

Kemp, David P. wrote:
> 
> As noted earlier, I think -03 has already gotten it right in

These two MUST NOTs and the two unexplained NOT RECOMMENDEDs
to which I'm opposed are clear violations of rfc-2119 section 6:

6. Guidance in the use of these Imperatives

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 16:37:03 +0100 (MET)

Yoav Nir wrote:
> Actually it's easier to hard-code the ciphersuite list on the client,
> because it never changes with most applications. Adding logic to
> differentiate between initial handshakes and repeated handshakes
> complicates the code (though not by much)

It more complicated than that, because SCSV is additionally necessary
for sensible behaviour even with -03 when doing old renegotiation
on a connection where the initial ClientHello did not use any
TLS extensions.

And it is a different question whether providers of an implementation
offer this configuration option (which a number of them likely has to),
or wether we recommend that this configuration setting is actually used.

These are two different guidances, and the -03 document does not
distinguish them, which is a bad idea.

> An empty extension is less easy IMO.

The concept that I had in mind when I created the label
TLS_RENEGO_PROTECTION_REQUEST was a signal that indicates
"Please protect me from an old-style TLS handshake"

And an old-style TLS handshake is one where you have no possibility
to detect whether there is an MitM attacking you.

> > be published as an RFC right now.

Process-wise, Pasi could have made a consensus call on exact SCSV
semantics on Dec 17th providing several options,  the result of a
free and open discussion on SCSV semantics could have been part
of -03, Pasi could have re-issued an IETF Last Call on Jan 7th, we
would have received further editorial comments and today
an -04 document could be in much better shape, ready for IESG
approval and in perfect alignment with the IETF processes.

> future, the way to indicate support for secure renegotiation would
> be in the client version of the ClientHello.

Unfortunately, that "go away" is impossible for any implementation
of TLS that offers interop with protocol versions 0x03,0x00 -> 0x03,0x03
(aka SSLv3 and TLS protocol version v1.0->v1.2).

And although clients could stop sending SCSV when they stop using
extension-less ClientHellos, the server-side support for SCSV is going
to stick forever.

Likewise, the TLS extension RI band-aid is going to be with us
for at least 20 years.  It's not possible to make this design
an integral part of a future TLS version that obviates sending
this data over the wire.  Except maybe defining an alternative
and negotiating that as well.  The latter could obviate transfering
the data, but would require implementations to implement essentialls
two solutions for the same problem, which, unless someone finds 
a problem with TLS extension RI (which I doubt), would be
a complete waste of resources.

I remember that Stephen Farrell suggested to standardize both
(TLS extension RI without SCSV plus a well-discussed successor
of draft-mrex-tls-secure-renegotiation), but *I* don't like
two solution where one is sufficient.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 27 Jan 2010 08:49:06 -0800

> on a connection where the initial ClientHello did not use any

I think you meant to write "necessary to prevent vulnerable renegotiation on
a connection where the initial ClientHello did not use any TLS extensions".
 If that is what you meant, please confirm.

What you wrote sounds more like you were expecting "old renegotiation" to
succeed.  If you were indeed expecting that, then why does SCSV play any
role in that at all?

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 18:18:01 +0100 (MET)

> If that is what you meant, please confirm.

It is necessary to actually perform an old-renegotiaion successfully
while at the same time preventing an attacker from being able to
proxy that old renegotiation into a renegotiation handshake of
an updated server that still allows backwards-interoperable
old renegotiation for old clients.

> succeed.

Correct, I am expecting that.

That is a configuration option that implementations (hotfixes into
installed base, early during the transition) are likely required
to offer.

That we recommend to discontinue old-style renegotiation is
a totally different issue.

>
> If you were indeed expecting that, then why does SCSV play any
> role in that at all?

The purpose of SCSV is to reliably prevent any undesired renegotiations
from being possible.  The only handshakes where you can reliably
distinguish desired from undesired is those between updated clients
and updated servers.  

If an implementation of TLS offers a configuration option to allow
old-style reneogitation for interop with installed base old servers,
then we should an can limit that fallback to old servers.  This is
what the brand-new section 4.2 tries to explain (although it is
in dire need of editorial fixes in order to become comprehensible).

-Martin

---

From: Bob Braden <[email-masked]>
Date: Wed, 27 Jan 2010 09:51:18 -0800

> document in the first place?

All in all, that pretty much sums up the current (and long standing) 
situation, IMHO.

Bob Braden

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 27 Jan 2010 10:55:31 -0800

> installed base, early during the transition) are likely required

In my code, I added three boolean configuration options
which all default to false:

     AllowUnsafeInitialConnect
     AllowRenegotiation
     AllowUnsafeRenegotiation

Hopefully this will make it obvious to people that choosing
the Unsafe options are just that (though the first one will
be needed for a while yet).

Mike

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 27 Jan 2010 14:13:00 -0500

> to which I'm opposed are clear violations of rfc-2119 section 6:

This is admittedly a strong argument.  However, in my opinion, alignment
with 2119 must be evaluated in light of:

> [Nikos]: I believe allowing the sending of both SCSV 
> and extension might harm interoperability instead.

and

> [Pettersen]: The SCSV is a temporary fallback, one that 
> will not be needed when clients enter strict mode, since 
> when that happens servers have to support the RI extension.

When the reality of development practices is taken into account, the
MUST NOTs arguably *are* being used to enhance interoperability, in
accordance with rfc-2119.

> It more complicated than that, because SCSV is additionally
> necessary for sensible behaviour even with -03 when doing
> old renegotiation on a connection where the initial
> ClientHello did not use any TLS extensions.

Say whaaaaat?  When doing old renegotiation, neither SCSV nor RI are
necessary because by assumption the client, the server, or both do not
support secure renegotiation.  If an old server requests a new client to
renegotiate, and:
1) the client ignores the RECOMMENDED refusal to renegotiate, and
2) the old server INCORRECTLY fails to ignore extensions, and
3) the client sends an RI extension as RECOMMENDED,
... then there may be a handshake failure, which sounds to me like the
desired outcome in such a broken circumstance.

If the client instead sends SCSV in order to dodge a handshake failure,
which is NOT RECOMMENDED, the server is prevented from immediately
detecting an attack.  Sending SCSV in this circumstance, far from being
necessary or sensible, sounds to me like reckless behavior - pushing the
envelope of legacy interoperability.

As above, it might enhance interoperability long-term if new clients
operating in secure renegotiation mode simply failed to renegotiate with
broken servers.  If I were for changes to -03 (which I am NOT!), it
would be to change NOT RECOMMENDED to MUST NOT send SCSV in insecure
renegotiation.

Dave

---

From: Marsh Ray <[email-masked]>
Date: Wed, 27 Jan 2010 14:25:22 -0600

> It is necessary to actually perform an old-renegotiaion successfully

It is impossible for an implementation of the SSLv3 or TLS specs to 
perform an "old-renegotiaion successfully" unless your definition of 
"success" accepts the possibility of a MitM remixing the plaintext.

Since SSL/TLS have promised to provide data integrity protection since 
the beginning, everything which follows in your analysis is irrelevant.

- Marsh

---

From: Robert Relyea <[email-masked]>
Date: Wed, 27 Jan 2010 12:40:42 -0800

>    (1) I prefer publishing the specification as-is. 
I confirm I prefer publishing the spec as-is

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 22:02:18 +0100 (MET)

> > and extension might harm interoperability instead.

This is a clear misunderstanding on the issue.

Secure renegotiation requires verification of the contents
of the verify_data contained in the renegotiation_info.
So if the presence of an empty RI or SCSV in a ClientHello
during a handshake that is a renegotiation to the server
confuses a server about having to match the verify_data,
then you have much more serious issues to worry about.

> > when that happens servers have to support the RI extension.

This is also a misunderstanding.  The requirement for the server
to recognize SCSV is PERMANENT, even in -03.  Clients may stop
sending SCSV when they stop sending extension-less ClientHellos
or SSLv2 CLIENT-HELLO, but the requirement for the server to
recognize SCSV is going to stick for just as long as the
support for TLS protocol_versions {0x03,0x00} to {0x03,0x03}

Personally, I believe it is not possible to create an argument
(that is not lame) to justify that violation of rfc-2119 section 6.

As previously mentioned, I have provided an explanation along the
lines of a semi-formal correctness proof that these signals do
not interfere with each other -- it only a bad choice of description
in the document. 

The only reason why this awkward exception was added to the document
is to make it less obvious that not making SCSV mandatory and getting
rid of empty RI on initial handshakes in ClientHello is a poor
engineering decision.

Just as it is often possible to simplify logic circuits to obtain the
results of complex boolean functions, the use of abstract architecture
and methodologies from functional correctness proofing can
help you simplify the results if you, for whatever reason, want
to combine two different implementations of the same feature
of an abstract architecture.

> support secure renegotiation.

For me, that's a deja-vu.  I've found myself pretty unsuccessful convincing
people at the abstract architecture level.  I always have to resort to
scaring people with depictions of attack scenarios to get their attention.

In case that you are a TLS implementor, then we DEFINITELY need that
brand-new section 4.2 in the -03 document fixed before publication.

It's been discussed during IETF Last Call of the -01 document:
 Martin Rex    http://www.ietf.org/mail-archive/web/tls/current/msg05151.html
 Marsh Ray     http://www.ietf.org/mail-archive/web/tls/current/msg05155.html
 Pasi Eronen   http://www.ietf.org/mail-archive/web/tls/current/msg05186.html

We in the IETF are supposed to provide the highest possible
interoperability, configuration options for policy and resonable
default settings.

Quoting section 4 from the -03 ("current") version of the WG document:

   4. Backward Compatibility

   Existing implementations which do not support this extension are
   widely deployed and in general must interoperate with newer
   implementations which do support it.  This section describes
   considerations for backward compatible interoperation.

What exact settings the consumer of the technology uses is up to
the consumer.  If you are worried about "original" TLS, then
your browser ought to have regular HTTP and FTP securely disabled?
(my browser does not even provide such a setting...)

>
> If an old server requests a new client to renegotiate, and:

If that was really the desired outcome, then our browsers would already
have old renegotiation securely removed for months.  Browsers probably
are the most regularly patched pieces of software we have.

No.  A client MUST send either RI or SCSV to an _old_ server on a
permitted old renegotiation so that this handshake can not be
proxied by an MitM into an initial handshake of a _patched_ server.

If the connection is not attack, that signal ends up being totally
ignored.  Which is exactly what the convoluted section 4.2 says.

> envelope of legacy interoperability.

That NOT RECOMMENDED makes no sense here and violates rfc-2119 section 6.

The general interop recommendation in TLS is that you get the highest
chance of interoperability if a client supplies the same parameters
in a renegotiation ClientHello that it applied in the initial
ClientHello on a connection.  Same for session resume on a new
connection.

If the client didn't send TLS extensinons in the initial ClientHello,
it is a pretty bad advice to start sending TLS extensions in the
renegotiation ClientHello, and it is in conflict with the general
recommendation for what TLS client should do for maximum interop
(send the same parameters in ClientHello).

And if the client does not want to renegotiate, then there is no
ClientHello to be sent but instead either a warning-level
no_renegotiation alert if the clients wants to try continue
talking or a fatal handshake_failure if the client wants to
abort the connection.

> would be to change NOT RECOMMENDED to MUST NOT send SCSV in insecure

That would not only violate rfc-2119, that would be completely
unreasonable.

I do _not_ mind if you do not care for backwards interop scenarios,
but I would recommend that you get out of the way of those who care
because they must provide it to their customers in a non-disruptive
fashion.  

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 22:16:06 +0100 (MET)

> the beginning, everything which follows in your analysis is irrelevant.

You can call it "in an interoperable fashion", if you prefer that.
The IETF is all about interoperability, even though the security
area is known (and frowned upon) for providing the most feature-rich
set of policy options with the purpose of breaking^H^H^H^H^H^H^H^H limiting
or "constraining" interoperability.

It refers to interoperability where at least one of the TLS peers
implements one of the existing protocol SSLv3 or TLSv1.0->1.2 but
not the TLS extension RI update.

Providing the interoperability in the protocol is the task of
the IETF TLS WG, implementing interoperability with the installed
base correctly is the task for the TLS implementor,
and deciding and configuring whether interoperability with
old peers on renegotiation handshakes is necessary, is the task
of the consumer of the technology (configurable policy options).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 22:39:57 +0100 (MET)

> All in all, that pretty much sums up the current (and long standing) 

In that case, it should be the task of the IETF process
(Document Shepard and responsible Area Director) to reduce the
amount of inappropriate uses of imperatives from rfc-2119.

I have never seen an IETF AD fight so passionately for the
addition of rfc-2119-violating and unreasonable imperatives into
a document such as Pasi is doing it now.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Jan 2010 14:15:16 -0800

>a document such as Pasi is doing it now.

The terms "fight" and "passionately" apply to others in the discussion (certainly to you, given the tone and humorously large number of posts), but not to Pasi.

--Paul Hoffman, Director
--VPN Consortium

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 27 Jan 2010 17:35:58 -0500

> of the consumer of the technology (configurable policy options).

Martin, you seem very concerned with interoperability, and i appreciate
your advocacy for that concern.  I also value interoperability, and want
to see a smoothly phased-in transition.  However, the TLS working group
is not *only* about interoperability; it is also about how to offer
well-vetted, well-understood, comprehensible communications security
properties to the users of TLS.

It's clear from this discussion that the communications security
properties that earlier (uh, make that "all existing") versions of TLS
offered were either simply wrong, or at least very widely misunderstood
by not only users of TLS but also many TLS implementers.

Having simple and clear rules for implementers to follow will produce
less-buggy software, which will improve our ability as a WG to fulfill
the promises of private and authenticated communication that have been
made from the beginning of the standard.

The part you're arguing about (MUST NOT show SCSV during non-empty RI,
as i understand it) may or may not overstep the bounds outlined in RFC
2119; but it does not affect the security guarantees, and it is
relatively easy to implement either way.   But we can't resolve the
clear outstanding security flaws in the protocol while we're still
quibbling about this sort of detail.  From what i can see, nearly
everyone else has moved on to building and testing interoperable
implementations, whether they agree with the MUST NOT or not.

That's not happening because they don't care about interoperability.
They care about interoperability *and* about offering functional
security capabilities to their users.

If i agree with you that the MUST NOT seems a bit excessive, can you
agree with me that it doesn't actually alter the security guarantees one
way or another?  Can we then move on, accept that the standard might be
a bit stricter than it needs to be, and implement it anyway?  I favor
publishing the -03 as it is because it looks like it resolves the
problem at hand, not because i think it has every word written in the
best possible way.

The bottom line is that *all* TLS (and SSL!) implementations need
patching.  The sooner we agree on what those patches should do, the
sooner we can start rolling them out, and the sooner we can get back to
the guarantees we thought we had with TLS in the first place.

Regards,

	--dkg

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 27 Jan 2010 18:06:58 -0500

Michael D'Errico's solution:

> In my code, I added three boolean configuration
> options which all default to false:
>
> Hopefully this will make it obvious to people that
> choosing the Unsafe options are just that (though
> the first one will be needed for a while yet).

... sounds quite reasonable.

But how many bits would it take to fully control how renegotiation is
performed assuming that -03 permits everything (contains no MUSTs/MUST
NOTs), and how many of those bits would any customers really want to
have or understand how to use?

	default (all others false - renegotiation not allowed, sends
neither SCSV nor RI)

Secure_renegotiation flag is True:
	AllowRenegotiationUsingExtension (sends RI) (Section 3.5
required by elimination)
	AllowRenegotiationUsingBoth (sends SCSV and RI) (Section 3.5
MUST NOT)

Secure_renegotiation flag is False:
	AllowUnsafeRenegotiationUsingSSLTLS (sends neither SCSV nor RI)
(uses legacy specs)
	AllowUnsafeRenegotiationUsingExtension (sends RI) (Section 4.2
recommended by elimination)
	AllowUnsafeRenegotiationUsingCipherSuite (sends SCSV) (Section
4.2 NOT RECOMMENDED)
	AllowUnsafeRenegotiationUsingBoth (sends SCSV and RI) (Section
4.2 silent)

For secure renegotiation, if you eliminate the MUST NOT in section 3.5,
then you must add a configuration somewhere (either hard coded or as a
configuration option) that determines how the software will behave.

For insecure renegotiation, backwards interop scenarios can be supported
non-disruptively in 3 different ways in accordance with -03, but they
can also be supported non-disruptively in a 4th way, by following the
RFCs for TLSv1.0-v1.2 and ignoring -03.

As a customer, I don't really care about having 4 different ways of
doing insecure renegotiation; I'd be just as happy using software that
acts like a legacy application when it talks to other legacy
applications, and where that legacy behavior can be turned off with a
single switch when interop isn't needed.

Dave 

-----Original Message-----

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 27 Jan 2010 15:39:57 -0800

> have or understand how to use?

I have one other related client option:  UseExtensions.  If it is
false, then SCSV is sent instead of RI.  If a renegotiation happens,
an RI is sent even though UseExtensions is false (though no others
are sent).

These 4 bits seem to be enough to fully control renegotiation
without moving to a callback-style interface.

Mike

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jan 2010 01:54:37 +0100 (MET)

> configuration option) that determines how the software will behave.

I'm sorry, I completely lost you.

Removing that MUST NOT simplifies the architecture, the protocol
and the implementations.  Guaranteed.  You will find out when
you implement this.

Discussing this at the theory level is much more difficult,
and likely the reason why there is so much discussion and
disagreement.

I know that pretty well.  I completely foobared the implementation
guidance in the initial version (-00) of my draft, because I hadn't
sufficiently thought about implementing it.

It is possible to do it at the theoretical level, though.
That's what I did with the -03 document when I implemented
it exactly according to my own spec in OpenSSL-0.9.8l.

> RFCs for TLSv1.0-v1.2 and ignoring -03.
 
I'm sorry, I can not follow.

Insecure renegotiation is what happens, if you do not abort renegotiation
in the consistent absence of secure renegotiation.

I do not understand what you are refering to with "in three different ways".

There are a number of constraints that need to be checked, and it
is up to the implementer whether he implements each check individually
with its own error handling and own error number, or wether he
combines certain conditionals, error handling and error codes.

The MUST NOTs and the NOT RECOMMENDEDs I'm objecting to are
completely invisible at both, the API level and in the policy configuration
that determines which kind of interoperability should be allowed.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Jan 2010 07:40:03 +0200

> two solution where one is sufficient.

There has been discussion about whether RI should actually hold the old verify_data, or whether that should be incorporated into the signature without explicitly sending it. We've settled on the former partly because it is easier to implement in existing code, and easier to explain to certify.

A new version of TLS (4.0?  It's time to stop explaining that three-point-one-means-one-point-zero) would have to be certified again anyway, so it might as well change the way Finished is calculated. Then you don't need either SCSV or RI.

Of course as long as you support older versions of TLS, you still need them, but fully 4.0 handshakes will need neither SCSV nor RI.

---

From: <[email-masked]>
Date: Thu, 28 Jan 2010 11:22:54 +0100

> a document such as Pasi is doing it now.

"Now"? "Addition"? 

I would like to remind you that version -01 of the document also 
very clearly prohibited sending the SCSV in secure renegotiation
ClientHello, and also used upper-case RFC 2119 keywords in that text.

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jan 2010 15:37:24 +0100 (MET)

> ClientHello, and also used upper-case RFC 2119 keywords in that text.

It could be that we are refering to different versions of -01,
the one on tools.ietf.org doesn't have a MUST NOT send, and in
particular, it does not have a MUST abort when received.

If you think that there an implied MUST NOT in there -- I can see
explicit MUSTs to the contrary in -01 and more so in -02!

What to send on renegotiations has been returned to the WG as a
discussion item, and that is also reflected by a pair of [TODO:]
items in the document.

-01 also has the following:

   5. Requirements for Sending and Receiving

   TLS clients which support this draft MUST generate either the
   "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
   cipher suite with every ClientHello.

which is _NOT_ limited to *initial* ClientHellos.

and -02 goes even further:

   5. Requirements for Sending and Receiving

   TLS clients which support this specification MUST generate either the
   "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
   SCSV with every ClientHello, including ClientHellos where session
   resumption is being offered.

   TLS servers MUST support both the "renegotiation_info" extension and
   the TLS_RENEGO_PROTECTION_REQUEST SCSV.  TLS servers which support
   this specification MUST generate the "renegotiation_info" extension
   in the ServerHello in response to any client which offers either
   "renegotiation_info" or TLS_RENEGO_PROTECTION_REQUEST in the
   ClientHello. 

These are all of the MUST & MUST NOTs in -01 on tools.ietf.org:

   Upon receipt of the "renegotiation_info" extension, both client and
   server implementations which support the extension MUST verify that
   it contains the correct contents as specified above.  If the contents
   are incorrect, then it MUST generate a fatal "handshake_failure"
   alert and terminate the connection.

   Servers MUST treat receipt of TLS_RENEGO_PROTECTION_REQUEST exactly
   as if the client had sent an empty "renegotiation_info" extension and
   respond with their own "renegotiation_info" extension.

                                                 TLS implementations
   MUST continue to comply with 7.4.1.4 for all other extensions.
   Servers MUST NOT select this cipher suite in any handshake, as it
   does not correspond to any valid set of algorithms.

                          Clients which do support renegotiation MUST
   implement Section 3 as well.

                 TLS servers which support this draft MUST generate the
   "renegotiation_info" extension in the ServerHello in response to any
   client which offers either "renegotiation_info" or
   TLS_RENEGO_PROTECTION_REQUEST in the ClientHello.

   Existing implementations which do not support this extension are
   widely deployed and in general must interoperate with newer
   implementations which do support it. 

   If clients wish to ensure that such attacks are impossible, they MUST
   terminate the connection immediately upon failure to receive the
   extension without completing the handshake. 

   If servers wish to ensure that such attacks are impossible they MUST
   NOT allow clients who do not offer the "renegotiation_info" extension
   to renegotiate with them 

   By default, TLS implementations conforming to this document MUST
   verify that once the peer has been identified and authenticated
   within the TLS handshake, the identity does not change on subsequent
   renegotiations.  For certificate based cipher suites, this means
   bitwise equality of the end-entity certificate.  If the other end
   attempts to authenticate with a different identity, the renegotiation
   MUST fail.  If the server_name extension is used, it MUST NOT change
   when doing renegotiation.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 28 Jan 2010 09:55:16 -0500

-----Original Message-----

The MUST NOTs and the NOT RECOMMENDEDs I'm objecting to are
completely invisible at both, the API level and in the policy
configuration
that determines which kind of interoperability should be allowed.

-----End-----

But they must not be invisible to you, as a code author, since you are
objecting to the lack of freedom to do things in different ways that are
visible outside the implementation.

And they are not invisible to someone examining bits on the wire,
because if they wished to color flows, they could distinguish
implementation A from implementations B, C, and D based on whether Hello
messages contained SCSV, RI, both, or neither.  There would be fewer
colors if -03 said SCSV MUST NOT be sent under any circumstances, or if
Michael's UseExtensions option was set.

It's been an interesting discussion, but I'm in most people's kill files
by now so I'll shut up.

Regards,
Dave

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jan 2010 15:56:47 +0100 (MET)

Yoav Nir wrote:
> 
> A new version of TLS (4.0?  It's time to stop explaining that
> three-point-one-means-one-point-zero) would have to be certified
> again anyway, so it might as well change the way Finished is
> calculated. Then you don't need either SCSV or RI.
> 
> Of course as long as you support older versions of TLS, you still
> need them, but fully 4.0 handshakes will need neither SCSV nor RI.

I could imagine that a part of the installed base might have an
interop problems with protcol_versions where the major_number
is != 0x03.  (I believe ours does). 

In order to allow servers to perform some plausibility tests on
the initial incoming data of a connection to recognize ClientHellos
and distinguish them from e.g. HTTP GET/PUT/... the protocol_version
at the record layer should IMHO use the lowest(!) protocol_version
acceptable to the client.

I'm also wondering about one thing I encountered not so long ago
during interop tests:  when a Server aborts a handshake while
processing the initial ClientHello on a connection, there seems
to be an uncertainty what protocol_version that alert will
use at the record layer and from which set of available alerts
it will be chosen.

If possible, the protocol_version for that alert (and therefore
the set of avaiable alert numbers) should --if possible-- be chosen
to match a protocol version _not_ exceeding the highest protocol_version
proposed by the client in client_version.  There may be TLS server
implementations that do not account for this yet.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jan 2010 16:07:44 +0100 (MET)

> implementations that do not account for this yet.

Ooops, bad memories.

The confusion I ran into was different and may apply only to the
specific case that the highest protocol_version offered by the
client in ClientHello.client_version is lower than the lowest
protocol_version offered/allowed by the Server  (so the server
should send back the alert with a protocol version lower than
it would accept for communication).

The problem gets more complicated for clients that send (for whatever
reason) a client version  {0x03,0x00} (aka SSLv3).  SSLv3 does not
define an alert protocol_version(70).  But sending this alert value
anyway (_while_ using the 0x03,0x00 protocol version on the record
layer for the alert packet!) is maybe still a good idea.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 28 Jan 2010 17:18:41 +0100

> then you have much more serious issues to worry about.

You are considering only the case where the extension is non empty. On
initial connection the extension is empty, thus checking for extension
or the SCSV has equivalent results.

regards,
Nikos

---

From: <[email-masked]>
Date: Thu, 28 Jan 2010 18:07:26 +0100

Martin Rex wrote:

> It could be that we are refering to different versions of -01, the
> one on tools.ietf.org doesn't have a MUST NOT send, and in

There are different styles of writing specification text; some people
prefer to use upper-case RFC 2119 keywords as much as possible; others
prefer normal English.

The TLS main specification (RFC 5246) is clearly in the latter camp,
and mostly avoids using RFC 2119 key words. For example, when
describing the processing of received ClientHello, the text just says:

   "The server will select a cipher suite or, if no acceptable choices
   are presented, return a handshake failure alert and close the
   connection."

For an implementor, this means the same thing as "MUST select a cipher
suite from the list sent by the client or, [...] , MUST return a handshake
failure...". The lack of RFC 2119 keywords doesn't mean that a
compliant server could, e.g., use a cipher suite that was not proposed
by the client, or do something else completely.

The relevant text from -01 version was quoted in my email on January
26, and I'm not going to repeat it here.  The text does not in any way
contradict the "MUST generate either [..]  or [..] in every
ClientHello" in Section 5; text elsewhere in the document explains
when the different cases apply. For example, that sentence taken alone
would allow sending just the SCSV (without RI) in secure renegotiation; 
something that's clearly forbidden elsewhere in the document.

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jan 2010 19:50:31 +0100 (MET)

> something that's clearly forbidden elsewhere in the document.

If "MUST send either empty TLS extension or SCSV" would "clearly"
mean a mathematical X-OR, then this should have been changed in -03.

-03 clarifies that it does _NOT_ imply X-OR, but Inclusive OR.

As you can see in the WG discussion, some implementors did _NOT_
read this to mean X-OR, and some asked for spelling out that it
means Inclusive OR.

The document quality, and in particular the inconsistencies in
the document were just to numerous to make any assessments which
specific semantics someone may have "confirmed" by humming for
the -01 document in the Last Call.

If anything, the explicit MUSTs are a much more reliable indicator
of what is meant, and that says that a server must accept both
signals in a client hello.  The rest is just inconsistent wording.

The use of the label TLS_RENEGO_PROTECTION_REQUEST is also a strong
indicator that Eric's attempt at defining what this represents
is not necessarily final or completely accurate.

And from the message that *I* am getting here, the explicit MUSTs,
that require to accept SCSV Inclusive-OR on every ClientHello
is considered a "substantial" characteristic, where a changes
requires consensus, while an initial attempt to describe the
characteristics is an editorial issue and could be changed
mostly at discretion of the author.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Jan 2010 11:10:20 -0800

>   renegotiation ClientHellos is allowed (but not required).

The metadiscussion is raging (in both senses of the word), but the number of people expressing an opinion has dropped to near zero. This is just a gentle nudge to those who care but have not responded to do so.

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jan 2010 21:20:17 +0100 (MET)

(2) I prefer *NOT* publishing the specification as-is, and instead
    prefer to remove the 4 accidentally added rfc-2119-incompliant
    imperatives from -03 back to the technically sensible semantics
    which had the original WG and IETF consensus.  The document editor
    has proposed fixed text to make this an editoral change from -02,
    so this change is not going to hold up the document.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jan 2010 21:52:04 +0100 (MET)

> or the SCSV has equivalent results.

I'm sorry, I fail to understand.

Look at the -03 document (server receiving ClientHello), and what
the removal of the rfc-2119 incompliant imperative in -03 will
mean for the text and what it will mean for the TLS implementation
(I'm leaving out the obviated tests in the test framework for simplicity).

You can look at it form every perspective, it's simple,
it's an obvious improvement, and will make it rfc-2119 compliant.

3.7. Server Behavior: Secure Renegotiation

   This text applies if the connection's "secure_renegotiation" flag is
   set to TRUE (if it is set to FALSE, see Section 4.4).

-  o  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.
   o  The server MUST verify that the "renegotiation_info" extension is
      present; if it is not, the server MUST abort the handshake.
   o  The server MUST verify that the value of the
      "renegotiated_connection" field is equal to the saved
      client_verify_data value; if it is not, the server MUST abort the
      handshake.

In Meta-Code this might look like this:

   extensions = GetHelloExtensions(hmsg, ptr, hmsg_len)

   if ( NULL!=cur_session->cipher_state ) {
      /* this is a renegotiation */
      if ( (secure_renegotiation) ) {
         /* this ought to be a secure renegotiation */

-        if ( scsv_flag ) {
-             send_alert( cur_session, AL_FATAL, AL_HANDSHAKE_FAILURE );
-             rc = ERR_POSSIBLE_RENEGO_ATTACK;
-             goto error_cleanup;
-        }
-
         ri_contents = get_RI_contents(extensions);
         if ( NULL==ri_contents ) {
              send_alert( cur_session, AL_FATAL, AL_HANDSHAKE_FAILURE );
              rc = ERR_POSSIBLE_RENEGO_ATTACK;
              goto error_cleanup;
         }
         
         if ( !verify_RI_contents(cur_session,ri_contents) ) { 
              send_alert( cur_session, AL_FATAL, AL_HANDSHAKE_FAILURE );
              rc = ERR_POSSIBLE_RENEGO_ATTACK;
              goto error_cleanup;
         }

-Martin

---

From: Bill Frantz <[email-masked]>
Date: Thu, 28 Jan 2010 13:31:46 -0800

[email-masked] (Paul Hoffman) on Thursday, January 28, 2010 wrote:

>The metadiscussion is raging (in both senses of the word), but the number of people expressing an opinion has dropped to near zero. 
>This is just a gentle nudge to those who care but have not responded to do so.

Let me cast a weak vote for:

My real interest is getting on to the next version of TLS. I hope it
includes changes designed to:

(1) Limit the effect of bugs in a particular feature to those who actually
use the feature. Very few applications actually used renegotiation, but all
were affected. The use of PKI for peer authentication might fall in this
category.

(2) Eliminate features which can reasonably be handled at the application
layer. To my mind, renegotiation for key/certificate change on long-lasting
connections falls in this category.

(3) Enable future security bug fixes to be handled by the industry standard
mantra, "Just upgrade to the latest version", instead of requiring hacks to
be compatible with versions back as far as SSL2. (I realize this is more of
a social than a technical goal.)

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was working, the
408-356-8506       | rate of systems being compromised would be going down,
www.periwinkle.com | wouldn't it?" -- Marcus Ranum

---

From: "tom.petch" <[email-masked]>
Date: Fri, 29 Jan 2010 14:42:55 +0100

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 28, 2010 8:10 PM
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation
detail

Tom Petch