Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Dec 2009 12:06:18 +0200

On Nov 30, 2009, at 5:37 PM, The IESG wrote:

> The IESG has received a request from the Transport Layer Security WG 
> (tls) to consider the following document:
> 
> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
>   <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-12-14. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.

I oppose publishing the current draft. 

There are two unresolved issues still being discussed on the TLS mailing list: 
 1. non-extension signaling for older versions (SSLv3 and maybe TLS 1.0)
 2. explicit vs implicit addition of old verify_data to the PRF (also known as fail-unsafe vs fail-safe)

I think the WG is converging, and that a couple of more weeks of discussion may lead to consensus. 

I agree with David-Sarah Hopwood that a last call (WG or IETF) is still premature.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Dec 2009 11:36:32 +0000

> I oppose publishing the current draft. 

I strongly support it.

I don't buy the claims that extension handling as required here
is so hard to implement and all clients & servers need modification
in any case. (Not that its really relevant, but writing that code
would be much easier that reading the recent TLS list traffic;-)

I also don't see any concrete benefit in not sending the verify
data over the wire, but I do see more possibility for error in
terms of how to incorporate that data if its not sent.

My comments on -01 are below. While I'd like to see these addressed
of course, I think progressing this document speedily is more
important than resolving my comments. I think the same applies
to all other comments that I've seen, both during IETF LC and
on the TLS list since this problem was announced.

Regards,
Stephen.

1. The reference for the HTTP splicing attack is still a
placeholder. "[REF]"

2. I don't see any particular reason why the ServerHello RI value
contains both client and server values. I think it'd be marginally
better if the server just sent its value since the current approach
makes it easier for a server to mess up the ordering.

3. (Crossing page 5/6) It says the both "MUST verify" that the
values are correct, but doesn't explicitly say how to verify
the values, but just "as specified below" - where below?
It might be good to be extra-clear here, and add e.g. "A correct
value is one that was the verify_data of the Finished message
from the previous TLS session, or else the "empty" value given
above."  or something like that.

4. I'm slightly concerned that middleboxes might barf on the
new ciphersuite. Be good if someone had tested that in the wild,
but I've not seen a mail that says that that's happened. (The test
I mean is inclusion of a totally new ciphersuite value, not the
inclusion of a previously-allocated-but-mostly-unused value.)

5. (Similar to above.) It'd be great if we had data to allow
us to recommend either the RI in the initial handshake or else
recommend the ciphersuite. I can see implementers not knowing
what to do there, leading to a 50-50 split in terms of who
does what, possibly leading to lack of interop. If it were up
to me, I'd remove the ciphersuite and just go with the RI.

6. Is there an explicit statement somewhere that servers MUST
support both the RI extension and the ciphersuite? If so, I
skipped over it, so maybe highlighting it somehow would be
good. If not, please add, so that someone generating tests
from the RFC's "MUST" statements generates one for that.

7. 6.2 says: "If servers wish to <<avoid attack>> they MUST
NOT <<do stuff>>" Isn't that equivalent to servers SHOULD
NOT? I think a SHOULD NOT is better. (And that's the form
used in section 7.)

8. I would be for removing the new requirement that the
identity not change. This spec is in response to one thing
and should only fix that thing. Any other considerations
should not get the "emergency" treatment being applied
here especially since there could be unforseen side-effects
of the additional change. (E.g. some deployed application
making use of an id-change.)

9. The security considerations and the introduction
should include a statement that another mitigation that's
useful in many cases is for a server to simply disallow
all renegotiation and encourage implementers to allow
deployments to control that.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 30 Nov 2009 22:10:02 +0100

On Nov 30, 2009, at 4:37 PM, The IESG wrote:

> [email-masked] mailing lists by 2009-12-14.

I support the move, contingent to two clean-ups to specified behavior:

1. Section 3 specifies "For ClientHellos which are renegotiating, this  
field contains the verify_data from the Finished message sent by the  
client on the immediately previous handshake", and "For ServerHellos  
which are renegotiating, this field contains the concatenation of the  
verify_data values sent by the client and the server (in that order)  
on the immediately previous handshake."

There is no good reason for this asymmetry of having just the client's  
verify_data in the client's message, but both the client's and the  
server's verify_data in the server's message -- the latter is pure  
overhead, both in the specification and in the on-the-wire protocol.   
To remove the overhead from both, the second sentence should be  
saying, "For ServerHellos which are renegotiating, this field contains  
the verify_data sent by the server on the immediately previous  
handshake" (according changes to dependent parts of the specification  
then should be made).

For earlier Internet Drafts in the series preceding draft-ietf-tls- 
renegotiation-01.txt (draft-rescorla-tls-renegotiation.00.txt, etc.),  
a reason to keep the current text would have been to maintain  
compatibility with early implementations of those Internet Drafts.   
However, draft-ietf-tls-renegotiation-01 has a newer  
TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks  
compatibility with those early implementations anyway.

(This means that now, changing the ServerHello extension definition as  
suggested above gives the beneficial side-effect of exposing premature  
implementations, besides merely avoiding overhead.  Those incomplete  
implementations will be more obviously incompatible because they'd  
still be using the protocol variant with overhead, instead of just  
differing subtly in the behavior if faced with  
TLS_RENEGO_PROTECTION_REQUEST.)

2. The Security Considerations section of draft-ietf-tls- 
renegotiation-01.txt (section 7) includes language that unnecessarily  
restricts the flexibility that the TLS protocol specifically provides  
for, regulating areas that the TLS standard intentionally does not  
specify (RFC 5246 section 1) -- the current Internet Draft says:

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

There is no security reason for this restriction.  This sounds like a  
bad and incomplete workaround for certain problems with TLS that the  
updated protocol does not need a workaround for at all, because the  
protocol update is all about properly *solving* those problems.

Keeping this language in the specification would have the weird  
implication that applications that *need* the flexibility provided by  
the TLS protocol (e.g., to allow renegotiation handshakes to switch to  
a different ciphersuite, which may require a different certificate)  
would have to to *skip* implementing the protocol update, and thus  
stay vulnerable.

The new restriction that draft-ietf-tls-renegotiation-01.txt tries to  
sneak in thus seems harmful both for interoperability and for  
security.  I haven't seen any signs of working group consensus on  
including this new restriction.

Bodo

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 30 Nov 2009 23:19:40 +0000

The IESG wrote:
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt

I believe the decision to take this draft to Last Call was premature, and
that further discussion in the WG is necessary before deciding whether to
adopt draft-ietf-tls-renegotiation or an alternative.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Marsh Ray <[email-masked]>
Date: Mon, 30 Nov 2009 15:52:44 -0600

Bodo Moeller wrote:
> overhead, both in the specification and in the on-the-wire protocol.  To
> remove the overhead from both, the second sentence should be saying,
> "For ServerHellos which are renegotiating, this field contains the
> verify_data sent by the server on the immediately previous handshake"
> (according changes to dependent parts of the specification then should
> be made).

Good point.

> For earlier Internet Drafts in the series preceding
> draft-ietf-tls-renegotiation-01.txt
> (draft-rescorla-tls-renegotiation.00.txt, etc.), a reason to keep the
> current text would have been to maintain compatibility with early
> implementations of those Internet Drafts.  However,
> draft-ietf-tls-renegotiation-01 has a newer
> TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks compatibility
> with those early implementations anyway.
> 
> implementations will be more obviously incompatible because they'd still
> be using the protocol variant with overhead, instead of just differing
> subtly in the behavior if faced with TLS_RENEGO_PROTECTION_REQUEST.)

I don't think any of those implementations have shipped, and I don't
think anyone has advertised that code as anything but experimental.

It might not hurt for the IANA to assign a different number to the
extension than what was used for testing.

> 2. The Security Considerations section of
> draft-ietf-tls-renegotiation-01.txt (section 7) includes language that
> unnecessarily restricts the flexibility that the TLS protocol
> specifically provides for, regulating areas that the TLS standard
> intentionally does not specify (RFC 5246 section 1) -- the current
> Internet Draft says:
> 
> "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."
> 
> There is no security reason for this restriction.

+1 Agree

> This sounds like a
> the TLS protocol (e.g., to allow renegotiation handshakes to switch to a
> different ciphersuite, which may require a different certificate) would
> have to to *skip* implementing the protocol update, and thus stay
> vulnerable.

Excellent point.

Although the sentence after the one you quoted seems to say that
implementations are allowed to do it anyway if they choose. Which raises
the question as to what this language actually means for the wire
protocol, anyway.

> sneak in thus seems harmful both for interoperability and for security. 
> I haven't seen any signs of working group consensus on including this
> new restriction.

Details about which certificates endpoints should be allowed or
forbidden to negotiate is outside the scope of this bugfix.

We should remove it.

- Marsh

---

From: Nasko Oskov <[email-masked]>
Date: Mon, 30 Nov 2009 21:58:05 +0000

Bodo Moeller wrote:
>> final comments on this action.  Please send substantive comments to 
>> the [email-masked] mailing lists by 2009-12-14.
>

I support the 01 version of the draft, assuming we address this point:

>restricts the flexibility that the TLS protocol specifically provides for,
>regulating areas that the TLS standard intentionally does not specify (RFC
>5246 section 1) -- the current Internet Draft says:
>
>handshake, the identity does not change on subsequent renegotiations. For
>certificate based cipher suites, this means bitwise equality of the
>There is no security reason for this restriction.  This sounds like a bad
>and incomplete workaround for certain problems with TLS that the updated
>protocol does not need a workaround for at all, because the protocol update
>is all about properly *solving* those problems.

I agree that this restriction is not necessary for solving the current
problem. If the section should stay, I would vote for making it a SHOULD and
definitely not a MUST.

>Keeping this language in the specification would have the weird implication
>that applications that *need* the flexibility provided by the TLS protocol
>(e.g., to allow renegotiation handshakes to switch to a different
>ciphersuite, which may require a different certificate) would have to to
>*skip* implementing the protocol update, and thus stay vulnerable.

What about certificate renewal? Once a cert is renewed, it is different when
it comes to bitwise comparison, yet it is the same identity. I do not think
doing bitwise comparisons and dealing with identity at the TLS layer should
be part of this draft.

Nasko

---

From: "Rob P Williams" <[email-masked]>
Date: Mon, 30 Nov 2009 12:54:36 -0500

I support this draft.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
The IESG
Sent: Monday, November 30, 2009 10:38 AM
To: IETF-Announce
Cc: [email-masked]
Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport
LayerSecurity (TLS) Renegotiation Indication Extension) toProposed
Standard

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
19412&rfc_flag=0

_______________________________________________
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: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 1 Dec 2009 10:32:31 -0800

I disagree that the last call is premature.  I realize that not everyone
is happy with all aspects of the current document but a clear majority
of people on the TLS list have voiced their support for it.  I do not
see any consensus that the existing approach is flawed, nor do I see
evidence of an emerging consensus on an alternative approach. 

This document fixes a serious security hole in TLS and so it is
important to finish it in a timely manner. While a minority of the WG
may feel that it this draft isn't exactly the way it would like, it does
address the relevant security issue. I don't feel that waiting several
more weeks to see if consensus forms around some other approach is
likely to be useful.

Joe
(Speaking as TLS Working Group Co-Chair)

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yoav Nir
> Sent: Tuesday, December 01, 2009 2:06 AM
> To: [email-masked]
> Cc: [email-masked] Group
> Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation 
> (Transport LayerSecurity (TLS) Renegotiation Indication 
> Extension) to Proposed Standard
> 
> 
> Exceptionally, comments 
> > may be sent to [email-masked] instead. In either case, please retain 
> > the beginning of the Subject line to allow automated sorting.
> 
>  1. non-extension signaling for older versions (SSLv3 and 
> maybe TLS 1.0)  2. explicit vs implicit addition of old 
> verify_data to the PRF (also known as fail-unsafe vs fail-safe)
> 
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 01 Dec 2009 19:31:04 +0100

> adopt draft-ietf-tls-renegotiation or an alternative.

I agree to this.

I will support the current draft-ietf-tls-renegotiation-01 if that is choice
of direction in the end of this last call.

However, the TLS working group has also been working hard to evaluate
whether an alternative solution could provide better integration with legacy
deployments and provide better security properties.

This last call was initiated before the WG members had any real chance to
express their choice of direction.

For the sake of completeness, the alternative approach was updated and
posted today and is available from:
http://tools.ietf.org/html/draft-mrex-tls-secure-renegotiation-02

It is my opinion that this draft offers two noticeable advantages over
draft-ietf-tls-renegotiation-01

1) By not sending verify data over the wire, this draft allows peers to
fail-safe as a result of implementation errors in cases where a
corresponding implementation error of draft-ietf-tls-renegotiation-01 leads
to a fail-unsafe situation.

2) It offers a solution where servers never have to parse data from TLS
extensions. This offers advantages when deploying the fix for legacy
implementations.

I would support if the choice of draft-mrex-tls-secure-renegotiation-02 as
the selected solution to the problem, or an update of
draft-ietf-tls-renegotiation-01 which incorporate the updated handshake
message hash calculation of draft-mrex-tls-secure-renegotiation-02 as an
alternative to sending verify data in the RI extensions.

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Dec 2009 20:05:44 -0700

On 12/1/09 7:49 PM, Martin Rex wrote:
> Stephen Farrell wrote:
> This might be confusion with ISO terminology.
> 
>    MUST       ==  SHALL
>    MUST NOT   ==  SHALL NOT
>    SHOULD     ==  RECOMMENDED
>    SHOULD NOT ==  NOT RECOMMENDED
> 
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].

It's always puzzled me why the boilerplate quoted above does not include
the phrase "NOT RECOMMENDED", given that RFC 2119 mentions it a mere
five paragraphs later:

   4. SHOULD NOT  This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Is this a spec bug in RFC 2119?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 20:04:39 -0800

> Behalf Of Peter Saint-Andre
> Sent: Tuesday, December 01, 2009 7:06 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: NOT RECOMMENDED (was: Re: [TLS] Last 
> Call:draft-ietf-tls-renegotiation)
> 

Probably.

According to
http://www.rfc-editor.org/errata_search.php?rfc=2119
it was reported as Errata ID 499 by Anders Langmyr on 2006-01-09.

-d

---

From: Chris Newman <[email-masked]>
Date: Tue, 01 Dec 2009 23:04:43 -0800

I strongly support publishing this draft either in its present form or with 
any modification that does not impact the protocol's security analysis.

This the most time-sensitive and security-critical IETF draft with respect 
to impact on the Internet community that I have seen in 17 years of IETF 
participation.  As such, I strongly support the decision to start IETF last 
call early as permitted by RFC 2418 section 7.4.  I also encourage the IESG 
to move this document to the front of the queue for all support 
organizations (Secretariat, IANA, RFC editor) when processing occurs and to 
avoid holding a blocking DISCUSS after the telechat unless that blocking 
issue is more serious than the ongoing presence of this TLS security 
vulnerability on the Internet.

===
Three changes to draft-ietf-tls-renegotiation-01 I consider important (but 
not blocking):

* The header should explicitly state it Updates RFC 5246, 4346, 4366, 2246. 
This
  gets forward pointers in the RFC index to increase chances implementers 
of those
  specs will also find this one.  This is also necessary for RFC 5246 as 
this creates
  an exception to a MUST NOT.

* There is an error-of-fact in the introduction; this is incorrect:
"   If certificate-based client authentication is used, the server will
   believe that the initial traffic corresponds to the authenticated
   client identity."
This statement is true only for application protocols with a badly designed 
state transition from unauthenticated to authenticated state.  That is 
primarily limited to HTTPS and protocols based on HTTPS.  It is not true 
for most other IETF application protocols including SMTP, POP, IMAP, LDAP, 
NNTP, BEEP and XMPP (however, I suspect all of these are impacted by the 
TLS vulnerability in other ways).  Changing "is used" to "is used with 
HTTPS" would correct the error.

* Nomenclature: when discussing TLS_RENEGO_PROTECTION_REQUEST, the term 
"cipher suite value" needs to be used instead of "cipher suite", and the 
text needs to explicitly state that TLS_RENEGO_PROTECTION_REQUEST is not a 
cipher suite (it is not sufficient to say it can't be negotiated).  This is 
important for evaluating implementations against government standards that 
dictate which cipher suites an implementation may advertise.

Evaluation relative to draft-mrex-tls-secure-renegotiation-03:

Kudos to Martin Rex for producing such a good alternate proposal.  The 
introductory text up to and including section 4.1 is very good and would 
improve draft-ietf-tls-renegotiation.  While I would support a consensus to 
publish the mrex document as the solution, I presently prefer 
draft-ietf-tls-renegotiation-01 for four reasons:
1. Running code: multiple implementations and interop testing was performed 
on an
   earlier version of draft-ietf-tls-renegotiation.
2. Impact to core protocol handshake: The mrex proposal alters the 
handshake to include
   data that is not exchanged in-protocol.  If this impacts PKCS#11 
hardware tokens or
   other SSL accelerators (an issue mentioned by Dr Stephen Henson on the 
TLS list on
   Nov 26, 2009 19:24:55 +0000) that could severely impact deployment.  I 
do not know
   if that concern applies to the mrex proposal, but I know it does not 
apply to the
   draft-ietf-tls-renegotiation.  The point being the mrex proposal 
requires more analysis
   to verify impact.  As we're in a hurry, I prefer to easier to analyze 
proposal.
3. Extensibility.  In my experience one of the protocol design features 
most important to
   get right is extensibility.  SSL/TLS didn't really get that right until 
v1.2 (which is
   causing problems now).  As draft-ietf-tls-renegotiation uses the TLS 
extension
   facility more extensively, it will help future-proof more 
implementations.
4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some 
circumstances.
   That approach is untested in the field and I have concerns it will 
negatively impact
   middleboxes.  As draft-ietf-tls-renegotiation allows use of either the 
cipher suite
   value or the extension for C->S signaling, that mitigates the concern -- 
the field
   can choose the mechanism that works best.

My take on some controversial issues:

* There may not be a sufficient number of "extension intolerant" SSL/TLS 
servers in operation to justify the added complexity of 
TLS_RENEGO_PROTECTION_REQUEST.  However, I do not object to inclusion as 
it's possibly helpful for some alleged extension intolerant servers 
compliant with early drafts of SSLv3 and it helped move closer to WG 
consensus.

* I believe Bodo Moeller's proposal to exclude client's verify_data from 
ServerHello improves the protocol, but I do not find it a blocking or 
compelling issue.

* I find the present text in security considerations on identity change 
mid-stream acceptable from my perspective as an application developer. 
However, I do not care if that text is included or excluded from the 
approved version as it is ancillary to the important core purpose.

* Changing the handshake hash to include the previous verify_data after 
renegotiation: In the abstract, I find the "fail safe" nature of including 
verify_data in the hash a better design than having to explicitly check 
validity.  However, I find that less compelling than issues 1 & 2 above. 
Particularly given that TLS already requires skilled implementers to get 
tricky details correct in a fashion that can not be easily verified (e.g. 
PRNG).

* Non-extension signaling for ServerHello: I am strongly opposed to using 
any mechanism other than TLS extensions for signaling in the ServerHello. 
I found all such proposals (including overloading the version field) far 
too risky.  As the earlier mrex draft proposing such mechanisms was 
replaced by a revision which now uses the extension mechanism, I believe 
the matter is settled.

		- Chris

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Dec 2009 11:12:26 +0200

On Dec 2, 2009, at 9:04 AM, Chris Newman wrote:
> participation.  

This is the part I disagree with.

New extensions to protocols will take years to deploy. There's no getting around this.

SSL/TLS servers that do not depend on renegotiation can disable renegotiations entirely. They can do this NOW.
SSL/TLS servers that rely on renegotiation only for the upgrade-to-mutual feature for web servers can disable client-initiated renegotiations, and tweak their web applications so that the prefix injection doesn't matter. The can do this NOW. (We did)

The only real case of using renegotiation that I've heard about was identity protection, where the client connects anonymously first, and then presents the certificate during the (encrypted) renegotiation. This is probably very rare, and accounts for a fraction or a percent of SSL use.

So I don't think we should sit on our thumbs or even wait until the next face-to-face meeting, but whatever the RFC says, it will take years to deploy on the general Internet. We should hurry, but we shouldn't rush into things.

---

From: Chris Newman <[email-masked]>
Date: Wed, 02 Dec 2009 08:11:55 -0800

--On December 2, 2009 11:12:26 +0200 Yoav Nir <[email-masked]> wrote:
>> This the most time-sensitive and security-critical IETF draft with
>> respect  to impact on the Internet community that I have seen in 17
>> years of IETF  participation.
>

Since that's a statement about my observations, you'd have to propose a 
different draft that better met that criteria in the last 17 years and get 
me to agree ;-)

> SSL/TLS servers that do not depend on renegotiation can disable
> renegotiations entirely. They can do this NOW. SSL/TLS servers that rely
> on renegotiation only for the upgrade-to-mutual feature for web servers
> can disable client-initiated renegotiations, and tweak their web
> applications so that the prefix injection doesn't matter. The can do this
> NOW. (We did)
>
> The only real case of using renegotiation that I've heard about was
> identity protection, where the client connects anonymously first, and
> then presents the certificate during the (encrypted) renegotiation. This
> is probably very rare, and accounts for a fraction or a percent of SSL
> use.
>
> So I don't think we should sit on our thumbs or even wait until the next
> face-to-face meeting, but whatever the RFC says, it will take years to
> deploy on the general Internet. We should hurry, but we shouldn't rush
> into things.

The problem is more a customer-service one than a purely technical one: 
there's a real problem with just turning off SSL/TLS renegotiation by 
default.  Yes, it's what vendors are working on doing, but it's just an 
interim solution.  Basically, a vendor has to go to an HTTP server customer 
and say:

   You need to patch your HTTP server to stop a security vulnerability 
<tech babble>,
   but it might break your server deployment if <tech babble>, you can work 
around
   that problem if you do <complex stuff> or <set flag so you stay 
vulnerable>.

It doesn't matter if the downside only impacts 1% of the HTTP server 
customers as the analysis of whether they'll be impacted may take time and 
money and that 1% may be the people who most urgently need the 
vulnerability fixed.  When the vulnerability in the IETF specification is 
fixed and has made it to 2-3 major browser vendors, the message to HTTP 
server customers becomes more reasonable (albeit still unsatisfactory).

While the <complex stuff> is feasible for a vendor with a small HTTP 
footprint and solid tech knowledge like yourself, it's less feasible for 
large corporate sites that would have to analyze thousands of HTTP-based 
services.

		- Chris

---

From: Bob Braden <[email-masked]>
Date: Wed, 02 Dec 2009 08:11:26 -0800

>>> NOT? I think a SHOULD NOT is better. (And that's the form
MUST NOT -> must not

The sentence is not an applicability/requirement statement. It is a 
statement containing fact in the real world.

Bob  Braden

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Dec 2009 08:23:10 -0800

Normative language is not affected by case.

In the IETF normative terms are typically capitalized, but there is nothing in 
their formal definition that requires this.

If a document has declared use of the standard normative terms, then it needs to 
use them ONLY for normative purposes.  If a particular instance is not meant 
normatively, then it needs to use different wording.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Chris Newman <[email-masked]>
Date: Wed, 02 Dec 2009 09:08:45 -0800

--On December 2, 2009 15:19:53 +0100 Martin Rex <[email-masked]> wrote:
>> 1. Running code: multiple implementations and interop testing was
>>    performed on an earlier version of draft-ietf-tls-renegotiation.
>
> Even EKR admitted that implementing the update is an insignificant
> amount of work.
>
> Pushing this point, that there were interoperable implementations
> when this proposal was made in the IETF smells very much like
> a request for rubber stamping.

The IETF's motto is "rough consensus and running code".  So "running code" 
matters.
"rubber stamping" is only a problem if incompatible changes are refused, 
but the fact such changes were made makes that straw man moot.

>> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in
>> some  circumstances.  That approach is untested in the field and I have
>>    concerns it will negatively impact middleboxes.
>
> Huh?  That sounds extremely unbelievable.

First, I'll reiterate that I found both proposals acceptable, so the four 
points I made were all matters of design preference for this situation and 
not issues I find strongly compelling.

The issue with middleboxes was raised by others and is a straw man.  There 
are government standards that have a fixed list of cipher suites and most 
clients can be configured to comply with those standards today.  Given the 
TLS standards available at the time, a middlebox which enforced the 
presence of just those cipher suites and no others in the TLS handshake 
would reasonably be expected to be forwards compatible.  Use of a 
mandatory-to-implement cipher suite value will require such middleboxes to 
be upgraded, thus slowing deploying.  I'm not a fan of middleboxes, but we 
shouldn't break them gratuitously.

>>    As draft-ietf-tls-renegotiation allows use of either the cipher suite
>>    value or the extension for C->S signaling, that mitigates the concern
>>    --  the field can choose the mechanism that works best.
>
> I consider this a defect in draft-ietf-tls-renegotiation-01.
> There should be exactly **ONE** signaling mechanism for the initial
> ClientHello on a connection so that extensions-tolerant but
> extensions-free Servers will not be force to wade through lists
> of extensions sent by clients.

I'd be fine with one signaling mechanism as long as it's the mechanism 
that's been standardized since 2006 and backwards-compatible with correct 
implementations since 1999 (TLS 1.0).  If we're misusing a cipher suite 
value as a protocol extensibility flag, an issue I'm willing to compromise 
on despite the lack of strong evidence it's necessary, we unfortunately 
need two signaling mechanisms: one that's standard that we know will work 
with modern correct implementations, and one a kludge that works with very 
old software, but might break good-faith modern implementations (like the 
middlebox straw man above).

> The existing fallbacks or conservative approaches give you a hint
> where you may expect interop problems.  TLS extensions are a known
> interop problem.

While I've seen evidence of bugs in TLS extension handling, and backwards 
compatibility fallback code that's been present in browsers since 1999, 
I've seen no evidence that extensions are an interoperability problem for 
correct standards-compliant TLS implementations or that such fallback code 
is necessary in operation today.

		- Chris

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 2 Dec 2009 18:16:46 +0100

I think that Stefan sums up the state of play well (after some 1,000 posts to
the TLS list with the number still rising steadily).

The IETF Last Call was premature, capricious even, given the ongoing debates on
the TLS list.

Technically, either draft will do but the mrex draft is superior in what I
regard as
system issues, in the likelihood of being deployed in such a way that it works.

Tom Petch

----- Original Message -----
From: "Stefan Santesson" <[email-masked]>
To: "David-Sarah Hopwood" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 01, 2009 7:31 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport
LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Dec 2009 12:18:10 -0700

>>> retain the beginning of the Subject line to allow automated sorting.

I've been following this draft since early Oct and support publishing it. I realize there are many things we could do and an infinite amount of time could be spend examine. I believe that lots of people have thought about the problem and solutions space and this draft represents a good compromise on acting soon vs analyzing the solutions space forever. 

Cullen <in my individual contributor role>

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 11:19:48 -0600

Martin Rex wrote:
> Chris Newman wrote:

My goal had been to present a usable solution along with the disclosure
of the vulnerability. When it comes to closing exploitable security
holes, a usable solution today is better than a perfect solution next
year. If that's rubber stamping to you, well sorry.

>>    handshake to include data that is not exchanged in-protocol.
>>    If this impacts PKCS#11 hardware tokens or other SSL accelerators
>>    (an issue mentioned by Dr Stephen Henson on the TLS list on
>>    that could severely impact deployment.
> 
> Crypto hardware in general and PKCS#11 are not affected.  What I am
> changing is the plaintext input to a hash or hash-like function.

Agree.

> What might be affected is hardware implementations of SSL/TLS
> or hardware-support for SSL/TLS in TLS endpoints.  It might be
> a firmware rather than hardware issue there.
> 
> So far, I haven't seen any vendor/implementor that is facing such
> difficulties raising such concerns.
> 
> Which could mean two things:
>  1. there is no problem
>  2. those vendors/implementors have not looked at / evaluated
>     the current proposals.
> 
> (1) would make it a non-issue and (2) would indicate than a decision
> in the IETF is _premature_, we would have to ask some of those
> vendors/implementers for feedback before making a decision.

I am a bit disappointed that we have not had better participation from
the vendors, particularly hardware. My suspicion is that they're
reticent to discuss what they're up against either publicly or privately.

We can't delay the solution for the large percentage of affected
deployments that are represented by vendors who did choose to
participate in the discussion for the sake of those who did not.

>>    circumstances.  That approach is untested in the field and I have

I suspect that some inspecting firewall or IDS box somewhere is going to
take issue with the new cipher suite value and have to be reconfigured.
I also believe that it's a minimal concern and it's the least-breaking
of all the possible signaling methods.

> Do any of the browser vendors cut down on ciphersuites in their
> current reconnect fallbacks -- and remove ciphersuites like
> those with AES?
> 
> A quick glance indicates that Firefox 3.0.15 happily sends
> a list of 18 ciphersuites, including Camellia, in an SSLv2 ClientHello
> on reconnect fallback.

My experiments were showing that some clients would advertise a reduced
list of cipher suites in the renegotiation hello.

>>    the field can choose the mechanism that works best.
> 

It's a three-to-five line 'for' loop.

> where you may expect interop problems.  TLS extensions are a known

Those servers need to be patched or you wouldn't want to trust
connecting to them anyway. Client implementations can use the MCSV
(magic cipher suite value) on the initial hello if they prefer.

> That cipher suite value is definitely not added complexity.
> On the contrary, it is significantly reduced complexity.

Well, there are now three ways to signal in an initial client hello. The
extension, the MCSV, or both.

Some implementations will find the MCSV simpler, some the extension.

> We are not discussing about a new optional feature here, but instead
> about something that should be patched into as many old clients and
> servers as possible.  And a number of clients MUST remain interoperable
> with servers that will _not_ be patched.  Therefore requiring anything
> that will break interop in the productive installed base is completely
> inacceptable when it can be avoided (which it easily can be).

+1

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Dec 2009 03:49:57 +0100 (MET)

MUST       ==  SHALL
   MUST NOT   ==  SHALL NOT
   SHOULD     ==  RECOMMENDED

And btw. the document that standardizes the secure renegotiation
will have to say that it updates RFC-5246, because it needs to.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Dec 2009 15:19:53 +0100 (MET)

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Dec 2009 19:35:50 +0100 (MET)

> but the fact such changes were made makes that straw man moot.

I remember the IETF discussions when S/MIME was brought to the IETF.

"Running code" for new implementations is _NOT_ an issue for the
decision we're doing here, since we agreed that the implementation
effort for either proposal is insignificant.

"Running code" as the installed base that draft-ietf-tls-renegotiation-01
might impair is _what_really_counts_.  The software logistics around
shipping a hotfix for a huge and in some instances very old installed
base is the running code that needs to be relevant for the IETF decision.

> not issues I find strongly compelling.

You asked me directly to write up my proposal in an I-D on Nov 16th:
http://www.ietf.org/mail-archive/web/tls/current/msg04400.html

I agreed to writing an I-D here:
http://www.ietf.org/mail-archive/web/tls/current/msg04410.html

The WG-Chairs summary for EKRs draft on Nov 18th:
http://www.ietf.org/mail-archive/web/tls/current/msg04464.html

WG-Chairs consensus call for EKRs draft on Nov 20th (Friday)
http://www.ietf.org/mail-archive/web/tls/current/msg04571.html

to which I replied that I will post my new I-D on Monday Nov. 23rd
(which I did), followed by a cleanup submission on Wed, Nov 25th.

Considering that EKR had been involved in Project Mogul a few weeks
before I realized the MITM-suceptibility of the TLS renegotiation
and posted about it to [email-masked], that he has been previously
authoring and co-authoring documents around TLS, I think it's unfair to
complain that my proposal is "late".  It's my first I-D and and I'm
not a TLS implementer myself (only responsible for maintenance, support
and updates of the OEM SSL/TLS implementation that my company is shipping).

> clients can be configured to comply with those standards today.

You mean stuff like this here: http://iase.disa.mil/stigs/stig/index.html

If you look at this governmental spec in particular (page 50):
http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf

then you should realize two things:

 - it requires support for SSLv2, which is mutually exclusive
   with a TLS extension (but fine with my proposal)

 - it refers to the configuration of cipher suites,
   and _NOT_ to the presence of ciphersuite IDs in ClientHello.

 - the explicit list in that document is to illustrate which of
   the _weak_ ciphersuites are not allowed, the underlying
   security requirement is strong encryption (128-bit).

Middleboxes aborting on the cipher suite selection on the server is
_much_ easier to implement and perfectly reliable.

Changes to filtering middle boxes (like intrusion detection systems)
is a moot point, because these are constantly updated anyway (which
is quite different from several of the SSLv2 Servers that are still
used in some places).  No one would be using AntiVirus-Software with
signatures that are several months or even several years old.

>
> Given the TLS standards available at the time, a middlebox which enforced
> the presence of just those cipher suites and no others in the TLS handshake 

If you look at the unix-stig-v5r1 standard, it does _not_ list
AES ciphersuites (RFC-3268, June 2002).
One would expect that those middle-boxes, if they care about the
cipher_suites in the _list_ of the ClientHello rather than the
negotiated cipher suite in ServerHello, should check the fixed
short list of known-to-be-weak cipher suites listed in the above
document rather than get in the way of future development
(the latter does not seem to be the intention of that spec).

> implementations since 1999 (TLS 1.0).

TLS extensions is _not_ a signaling mechanism, and the 
"backwards-compatibility" amounts to "should be safely ignored when
present, but we never actually tested that".

It has been an optional and generic extension mechanism which the IETF
never cared to make attractive until November 2009.  Suddenly some
folks want to make a hardly used optional feature a mandatory-to-implement
functionality for all SSLv3 and TLS protocol versions back to 1994.
(oh no, wait -- until ~nov 17th they were determined to simply kill all
 interop with SSLv3 and extensions-intolerant implentations of TLSv1.0).

The original SSLv3 spec from Netscape did _not_ have the forward compatibility
in ClientHello necessary for the installed base to not choke on the
presence of TLS extension.   Only the updated I-D document for SSLv3
that was produced in the IETF TLS working group (18-Nov-1996) had such a
forward compatibility provision, however the TLS WG did _not_ care to
publish that document as an informational RFC back then (so it was
expired from the I-D repository 6 month after publication).

And Netscape continued to provide the pretty PostScript & HTML
spec of their SSLv3 spec without extensibility _much_ more prominently
than the abandoned SSLv3 draft from the IETF TLS WG.

TLS extensions (rfc-3546, June 2003) was a hardly-used option that
came several years after TLSv1.0 (rfc-2246, Jan 1999) and was still
a pure option in TLSv1.1 (rfc4346, April 2006) and not part of the
TLSv1.1 base spec.

>                                         If we're misusing a cipher suite 

I'm sorry to disagree, but

if a "modern correct implementation" has a problem with a signaling
mechanism based on a cipher suite value in the ClientHello.cipher_suites
list, then this implementation is neither modern nor correct!

> is necessary in operation today.

The IETF is fully aware that

  - the TLS rengotiation problem affects all protocol version of
    TLS including SSLv3 and in exactly the same fashion

  - it is extremely important that as many of the installed base
    is patched so that the number of servers and clients that
    need to tolerate and provide backwards interoperability
    with unpatched TLS peers can be reduced to a minimum.

It is completely irrelevant how nicely this update fits with
the most recents TLS implementations from the fancy new features
department.

What is extremely important is the interoperability with the
RUNNING CODE out there maintained by the poor souls from the
dirty old cruft department -- and how much hazzle it means
for them to adopt this update.

And it is much more about risk management for backwards-incompatible
changes of a protocol and software in a potentially disruptive
fashion for a productive installed base than it is about testing
new features in a limited amount of new test installations where
interop issues can be addressed and fixed with no time pressure
whatsoever.

-Martin

---

From: <[email-masked]>
Date: Wed, 2 Dec 2009 02:27:21 -0500

>The IESG has received a request from the Transport Layer Security
>WG (tls) to consider the following document:
>

My colleagues and I support this draft. We would like the following to be 
considered:

In section 1 there is a missing full stop:
>thus be detected This
Should be:
>thus be detected. This

In section 1, there is a reference to the extension prior to it being defined.
Perhaps the following should be changed from:
>An attempt by an attacker to inject himself as
>described above will result in a mismatch of the extension and can
>thus be detected
To:
>An attempt by an attacker to inject himself as
>described above will result in a mismatch of the handshake hash and can
>thus be detected

In section 1, an ID is mentioned. I am not sure it adds anything to the 
specification having this here. Perhaps if the purpose is to acknowledge the 
people who created the draft, they could be acknowledged in the 
Acknowledgements section. Given this, I think that the following should be 
removed:
>The extension described here is similar
>to that used for TLS Channel Bindings
>[I-D.altman-tls-channel-bindings].
If this were to be removed, the text in section 3 would also need to be 
removed:
>Note that this value is the "tls-unique"
>channel binding from [I-D.altman-tls-channel-bindings]

In section 3 the term "TLS resumption" is used. In RFC5246 I think this is 
typically referred to as "session resumption". Perhaps the text should be 
changed from:
>The above rules apply even when TLS resumption is used.
To:
>The above rules apply even when TLS session resumption is used.

In section 4 there is a typo, a " is missing and the word "in" is missing.
This line should be changed from:
>"renegotiation_info" extension, only renegotiation_info" may be used
>rehandshakes.
To:
>"renegotiation_info" extension, only "renegotiation_info" may be used
>in rehandshakes.

In section 4 last paragraph it discusses a minimal client. It says:
>Any compliant server will reject any (apparent) attempt
>at renegotiation by such a client.
And in section 3 it says:
>If the contents
>are incorrect, then it MUST generate a fatal "handshake_failure"
>alert and terminate the connection.
This implies that the cipher suite is not entirely equivalent to an empty
renegotiation_info extension. If a server receives an empty renegotiation_info 
extension on a rehandshake then it must generate a fatal "handshake_failure" 
alert and terminate the connection rather than merely rejecting the 
renegotiation (by generating a "no_renegotiation" alert at warning level).
I think that the paragraph in section 4 should be altered to say:
>Any compliant server MUST generate a fatal "handshake_failure"
>alert and terminate the connection when it sees any (apparent) attempt
>at renegotiation by such a client.

In section 6.1, it says the word "rehandshakes" when I think that it should 
say "renegotiates". Hence, change from:
>reject all rehandshakes and simply not signal it.  However, it is not
To:
>reject all renegotiates and simply not signal it.  However, it is not

Peter
------------------------------------------------
Peter Robinson - [email-masked]
Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, 
AUSTRALIA.
Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: Tuesday, 1 December 2009 1:38 AM
To: IETF-Announce
Cc: [email-masked]
Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport 
LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19412&rfc_flag=0

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Dec 2009 20:30:09 +0100 (MET)

> year. If that's rubber stamping to you, well sorry.

I know _you_ were very open-minded about the SSLv3 interop issue from
the beginning and I really value _your_ feedback in the discussion.

I wrote up my proposal after realizing that some people just did
not care about the obvious and serious disruptive nature for the
interoperability in productive environments and existing usage scenarios
of the original proposal which contained this:

  4.3. SSLv3
				
    SSLv3 does not support extensions and thus it is not possible to
    securely renegotiate with SSLv3.

> reticent to discuss what they're up against either publicly or privately.

One vendor that contacted me has just started to evaluate the
proposals.  I could conceive that there are a number of vendors/suppliers
that would not know how to participate the discussion or voice their
concerns.  Sometimes it is as simple as there is nobody sufficiently
experienced and with sufficient time available and permission from
his management to enter the discussion on [email-masked].

> participate in the discussion for the sake of those who did not.

I know that the vendors (and in particular their customers) who
had been actively using the TLS renegotiation for delayed client
authentication want to get a solution out there.

The short-term solution to the security problem would be to
disable renegotiation and request the certificate on initial
handshake only.  This impairs the user experience slightly,
but would not kill interop completely (hmmm, it could, due to
an interop-problem in WinHTTP, but I reported that in 2005...)
... unlike a requirement for a TLS extension in initial ClientHellos
for a number of existing usage scenarios.

So if we lack feedback from vendors, we should actively reach
out and collect this feedback.  The sooner the better.  It's
not like those vendors all live on alpha-centauri.

> It's a three-to-five line 'for' loop.

maybe you missed the "extensions-free" part.  Just like it is possible
now for a significant amount of the servers out there to simply
disable renegotiation, the hotfix for those servers should allow
them to ship an update entirely without TLS extensions support and
renegotiation still disabled.  There, a single REQUIRED signaling
option that does not need generic extensions support makes
a HUGE difference.  Search for the cipher suite (that code exists),
append a short static string to ServerHello and be done with it.

You are not seriously suggesting that such servers should become
extensions-intolerant in order to be served the easy-to-recognize
magic cipher suite value, are you?

> Some implementations will find the MCSV simpler, some the extension.

It simply makes no sense to create a new protocol feature with
more than one signaling mechanism.  This is unnecessary complexity
for the implementations and for the interop testing.  

The magic cipher suite signaling needs to be a MUST,
the inclusion of an empty TLS extension in the ClientHello
probably a SHOULD NOT.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 02 Dec 2009 14:52:42 -0800

+1

> If we're misusing a cipher suite value as a protocol extensibility flag,
> an issue I'm willing to compromise on despite the lack of strong evidence
> it's necessary, we unfortunately need two signaling mechanisms: one
> that's standard that we know will work with modern correct
> implementations, and one a kludge that works with very old software, but
> might break good-faith modern implementations (like the middlebox straw
> man above).
> 
>> The existing fallbacks or conservative approaches give you a hint where
>> you may expect interop problems.  TLS extensions are a known interop
>> problem.

 ... for servers that have never been conformant with the standards that
require them to ignore unknown extensions, yes.  Another way to say this is:
non-conformant servers are a known interop problem for conformant clients.
That fact is manifestly obvious now, as we see attempts to retroactively
codify the behavior of those non-conformant servers as we try to fix this
problem.

> is necessary in operation today.

+1.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 07 Dec 2009 08:34:29 +0000

> years of IETF participation.

Standard vendor response is to disable broken protocol features.  This
has been done countless times for core protocols, and I guess it would
work here, too.  Fixing the protocol is desirable, but there's still a
backup plan.  Let's not pretend otherwise. 8-)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Steve Checkoway <[email-masked]>
Date: Mon, 7 Dec 2009 02:31:23 -0800

I support this draft.

-- 
Steve Checkoway

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 7 Dec 2009 11:10:45 -0800

> >   <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard

Ditto.

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Dec 2009 02:05:08 +0100 (MET)

Chris Newman wrote:
>    on an earlier version of draft-ietf-tls-renegotiation.

I have published a diff for OpenSSL-0.9.8l that implements
draft-mrex-tls-secure-renegotiation-03.txt.

ftp://ftp.sap.com/pub/ietf-work/tls/

It amounts to ~120 Lines-of-Code (180 if you include empty lines and braces).

It is less than half the code footprint of the TLS extension RI 
that is contained in openssl-0.9.8-stable-SNAP-20091205,
(and that TLS extension RI implementation is based on an earlier
 proposal, doesn't have the MCSV yet, so lacks support for SSLv3
 SSLv2 ClientHellos, conservative clients and reconnect fallbacks
 and protection from downgrade attacks.)

So if you're in a hurry, here is a document in better shape,
an implementation in better shape, which requires less code
changes -- in particular for old implementations that do not
contain TLS extensions (how to implement S->C signaling with
no TLS extensions coding is part of my patch for OpenSSL and ~20 LoC).

As has been previously discussed, there are very few code paths
and a failSAFE design, so this approach is _much_ easier to test
than TLS extension RI.

>    handshake to include data that is not exchanged in-protocol.

My proposal does not "alter" the handshake.  It just defines extra
handshake messages that are _NOT_ transferred over the network
(since both peers already have it, there is no need to acutally
send them).

>    The point being the mrex proposal requires more analysis

I don't see a need for further analysis.  I put more thought on this
one now than I put into finding the TLS renegotiation vulnerability,
so by now I pretty sure it is as sound, safe and secure as the
rest of the TLS handshake design.  There are _no_ new concepts.

>    most important to get right is extensibility.  SSL/TLS didn't really
>    get that right until v1.2 (which is causing problems now).
>    As draft-ietf-tls-renegotiation uses the TLS extension

It doesn't simply "use", draft-ietf-tls-renegotiation will _require_ it
back to 1995 and be quite hostile about interop with the installed base

If you want an example for "use" of TLS extension in a non-offending fashion,
draft-mrex-tls-secure-renegotiation-03 "uses" TLS extensions.

> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST
>    in some circumstances. That approach is untested in the field

This claim is quite unsubstantiated.

My proposal requires TLS_RENEGO_PROTECTION_REQUEST, but adding new
ciphersuites is something that has been done many times before quite
successfully.  The AES ciphersuites (rfc3268,June 2002) came before
TLS extensions and didn't remotely cause any of the interop problems which
TLS extensions were found to cause.

Today, Firefox 3.0 will send Camellia ciphersuites in a SSLv2 ClientHello.

There is fairly broad consensus in the TLS WG that the extensibility
of the cipher_suites field in ClientHello has by far the least number
of interop problems in the TLS protocol.

Severe interop problems are known for TLS protocol versions and 
presence of TLS extensions.

> compliant with early drafts of SSLv3 and it helped move closer to WG 

The Complexity of TLS_RENEGO_PROTECTION_REQUEST is a magnitude smaller
than that of a TLS extension RI in the initial ClientHello (and in
renegotiation ClientHellos during backwards interop with old servers).

You can see from the OpenSSL diff I provided above, just how much
smaller and easier to implement the MCSV is compared to TLS extension RI.

> replaced by a revision which now uses the extension mechanism, I believe 

Thanks.  I said from the beginning that I'm open to suggestions
for the Server->Client signaling.  And I adopted the solution from
draft-ietf-tls-renegotiation-01.txt after it had been added there.

-Martin

---

From: "Tom.Petch" <[email-masked]>
Date: Sun, 13 Dec 2009 18:18:04 +0100

Since this last call was issued, there have been a further 340 messages posted
to the TLS list about how to tackle this topic, a degree of activity some I-Ds
may not see in their entire life cycle.  This does suggest to me that consensus
may yet to be reached on the best way forward for this topic and as such, the
I-D is not yet ready to progess.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 30, 2009 4:37 PM
Subject: Last Call: draft-ietf-tls-renegotiation (Transport Layer Security(TLS)
Renegotiation Indication Extension) to Proposed Standard

> IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19412&rf
c_flag=0
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce