Subject: 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: "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

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

---

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: Paul Hoffman <[email-masked]>
Date: Tue, 26 Jan 2010 10:15:11 -0800

At 6:57 PM +0100 1/26/10, Martin Rex wrote:
>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.

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

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

--Paul Hoffman, Director
--VPN Consortium

---

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

On Jan 27, 2010, at 12:50 AM, Kemp, David P. wrote:

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

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)

> 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

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

> 4. The "identical" version is ready to go, in the form of -03 that can
> 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"

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

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.

> 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

---

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.

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

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: Martin Rex <[email-masked]>
Date: Wed, 27 Jan 2010 18:18:01 +0100 (MET)

Nelson B Bolyard wrote:
> 
> On 2010-01-27 07:37 PST, Martin Rex wrote:
> > Yoav Nir wrote:
> 
> 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.

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.

> 
> What you wrote sounds more like you were expecting "old renegotiation" to
> 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: "Kemp, David P." <[email-masked]>
Date: Tue, 26 Jan 2010 17:50:23 -0500

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

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

http://www.ietf.org/mail-archive/web/tls/current/msg05466.html

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

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.

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* have never suggested and do not endorse the specific
SCSV semantics as described in the -03 document.

-Martin

---

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

-Martin

---

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

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: "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: 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: 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: <[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: Marsh Ray <[email-masked]>
Date: Wed, 27 Jan 2010 14:46:47 -0600

Yngve Nysaeter Pettersen wrote:
> 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.
> 
> Extensions, or this is not known

And you're willing to put the client at risk by possibly connecting to a 
vulnerable server which may have buffered input data from MitM and is 
willing to renegotiate.

>, and
> extension _and_ that does not tolerate TLS Extensions

In that case, you were already pwned at the initial connection.

>, just in case this 
> we want the connection shut down. If the server tolerates extensions 
> then only the RI extension should be sent.

As a general-purpose TLS client:
1. Don't connect to a server without RI.
2. If you ignore (1), don't send SCSV when you renegotiate.

As a general-purpose TLS server:
1. Don't allow connections without RI.
2. If you ignore (1), don't renegotiate.

- Marsh

---

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: 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