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

> -----Original Message-----
> 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
> 
> 
> > 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.
> 
>  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: Robert Relyea <[email-masked]>
Date: Tue, 01 Dec 2009 10:45:16 -0800

On 11/30/2009 07:37 AM, The IESG wrote:
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt
>
>
> 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
>   
I support this draft. I'm not excited about an altogether different
signaling strategy for SSL v3, but it's not a big enough issue to hold
up this draft. The need is to great to have religious squabbles hold it
up any longer.

bob

---

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

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

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

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

-Martin

---

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Wed, 02 Dec 2009 07:46:53 +0000

> will have to say that it updates RFC-5246, because it needs to.

And RFCs 2246, 4346, and 4366.

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

---

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: <[email-masked]>
Date: Wed, 2 Dec 2009 14:33:02 +0100

Bodo Moeller wrote:

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

Note that this text is qualified by "except if the application asks
for it" -- so applications that need this flexibility can have it.
(But somehow quite many people have missed this, so it's clear
the text isn't sufficiently clear as-is...)

Best regards,
Pasi

---

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

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

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

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.

>    circumstances.  That approach is untested in the field and I have
>    concerns it will negatively impact middleboxes.

Huh?  That sounds extremely unbelievable.

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.

>
>    As draft-ietf-tls-renegotiation allows use of either the cipher suite
>    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.

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

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

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

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

-Martin

---

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: Chris Newman <[email-masked]>
Date: Wed, 02 Dec 2009 09:08:45 -0800

> 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

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.

>>    value or the extension for C->S signaling, that mitigates the concern
>>    --  the field can choose the mechanism that works best.
>

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

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

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: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 11:19:48 -0600

> a request for rubber stamping. 

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.

> changing is the plaintext input to a hash or hash-like function.

Agree.

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

> Huh?  That sounds extremely unbelievable.

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.

> a list of 18 ciphersuites, including Camellia, in an SSLv2 ClientHello

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

> of extensions sent by clients.

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.

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

> inacceptable when it can be avoided (which it easily can be).

+1

- Marsh

---

From: Nasko Oskov <[email-masked]>
Date: Wed, 2 Dec 2009 17:26:44 +0000

Pasi Eronen wrote:
>Note that this text is qualified by "except if the application asks for it"
>-- so applications that need this flexibility can have it.
>(But somehow quite many people have missed this, so it's clear the text
>isn't sufficiently clear as-is...)

I think it was clear enough, but I still believe we should not be changing
such behavior as part of fixing the MiTM problem. A malicious endpoint of
either end is not something we are trying to solve.

Changing default behavior for apps will have potential to break things that
we are not aware of. Asking each app to change to account for this new
behavior is only going to make deploying this fix slower.

I have heard of applications that rely on very short certificate lifetimes,
so a long lived TLS session with certificate renewal at some point will
cause breakage, while it will work just fine in today's world. 

Binary comparisons of certificates is not an adequate comparison of identity
and TLS relies on the application to do the right thing when it comes to
identity.  If we must keep this part, why not change it to a SHOULD to allow
vendors the flexibility of choosing which way to go? Leaving it a MUST creates
a problem for implementers that do want to implement the draft but want to
minimize breaking changes to the protocol.

Thanks,
Nasko

---

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

> either end is not something we are trying to solve.

It also represents the first toe into the water of the TLS spec
dictating the library<->app interface.

Which is a whole nother discussion I think we would be wise not to
bundle into this bug fix, as interesting as it will be.

- Marsh

---

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: 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: 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: Eric Rescorla <[email-masked]>
Date: Wed, 02 Dec 2009 12:08:49 -0800

At Mon, 30 Nov 2009 10:31:35 -0600,
Marsh Ray wrote:
> 
> A few little suggestions, mostly wording.
> 
> The IESG wrote:
> http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01
> 
> [Page 3]
> >    renegotiation handshakes to the enclosing TLS channel, thus allowing
> >    the server to differentiate renegotiation from initial negotiation,
> >    as well as preventing renegotiations from being spliced in between
> >    connections.  
> 
> "spliced in between sessions."

Hmm... I'm not sure that's quite what we want either. Maybe 
"between transport layer connections"?

> [Page 5]
> >    o  For ClientHellos which are renegotiating, this field contains the
> 
> "the renegotiated_connection field contains"

Agreed.

> >    Note that a minimal client which does not support renegotiation at
> >    all can simply use this cipher suite in all initial handshakes.  Any
> >    compliant server will reject any (apparent) attempt at renegotiation
> >    by such a client.  Clients which do support renegotiation MUST
> >    implement Section 3 as well.
> 
> I suggest we replace all uses of "cipher suite" in this section with the
> term "cipher suite value", and we add explicit wording "The
> TLS_RENEGO_PROTECTION_REQUEST cipher suite value is just a flag, it does
> not actually a refer to a set of cryptographic algorithms that could
> ever be used for data transmission."
> 
> This might seem obvious to all of us, but this wording change could
> conceivably speed review and fend off questions by some review board.

Works for me.

> >    TLS clients which support this draft MUST generate either the
> > 
> >    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
> >    cipher suite with every ClientHello.
> 
> Can they generate both?
> 
> If not, what does the server do if he receives both?

I see several possibilities:

- One or the other and the server MUST abort if he receives both. 
- Either or both on initial handshakes, but RI only on rehandshakes
- RI MUST be present on rehandshakes. The MCSV MAY be present
  but MUST be ignored.

The last of these would obviously require slightly altering the
"exactly the same" rule, so seems less desirable, but really any
of these are easy to do. I think my preference would be for the
first.

> >    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
> 
> s/must/need to/ to avoid confusion with MUST.

Works for me.

> >    If a client offers the "renegotiation_info" extension or the
> >    TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not
> >    reply with "renegotiation_info" in the ServerHello, then this
> >    indicates that the server either does not support secure
> >    renegotiation or is unwilling to use it.
> 
> Is it allowed for a patched server to be "unwilling"?
> 
> If not, drop the "or is unwilling to use it" lest it give the impression
> that such behavior is condoned.

Works for me.

> >    If the client does not offer the "renegotiation_info" extension or
> >    the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this indicates
> >    that the client does not support secure renegotiation or is unwilling
> >    to use it.  However, because the above attack looks like two
> 
> Again, is it allowed for a client to be conformant to this spec and
> still not send either the extension or magic cipher suite value?

Works for me.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 02 Dec 2009 12:26:44 -0800

> of these are easy to do. I think my preference would be for the

Option 3 is clearly better.  If a client sends the proper data within
the RI extension, it seems silly for the server to abort the connection
because of the presence of the cipher suite marker.  It is also easier
for a client to always send the cipher suite value rather than have a
conditional code path.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 14:34:29 -0600

> the beginning and I really value _your_ feedback in the discussion.

Thanks. I don't want to say how close I was to endorsing your proposal
and why I didn't (it would sound like an underhanded debate tactic in
what is still an ongoing discussion).

>     securely renegotiate with SSLv3.

It seemed reasonable at the time, we were under the impression that TLS
1.0 had been around for about 11 years and SSLv3 was all but dead.

We had vendors participating in Project Mogul who were sitting on
mountains of hard data about usage statistics and they never produced
anything of value in a timely manner. Perhaps they saw profit in a
breaking change, or perhaps they just didn't see the bigger picture.

Thanks to someone at F5 for sharing the statistic that 22% of current
traffic was SSLv3, and to the web browser vendors who all shared that
they maintained fallback reconnect logic to SSLv3.

> proposals.

Better late than never I suppose.

> I could conceive that there are a number of vendors/suppliers
> concerns.

I don't buy that. More than one just emailed me and said "hi, how do I
participate?" or "who in our company has been in contact?".

This isn't exactly a secret mailing list.

> Sometimes it is as simple as there is nobody sufficiently

IMHO, if an organization cannot not empower even a single engineer to
represent its interests in an issue as important as this, it ought to
get out of the internetworking business.

> handshake only.  This impairs the user experience slightly,

It's an impossible change for a major e-retailer, particularly this time
of year.

> an interop-problem in WinHTTP, but I reported that in 2005...)

Something our PhoneFactor Agent software uses in some places.

> not like those vendors all live on alpha-centauri.

Every vendor has heard about it now. We have gotten participation from
at least OpenSSL, Mozilla, Microsoft, Nokia, Cisco, Juniper, IBM, GNU
TLS, F5, Sun, RSA, Opera, SAP, Apple, and others. That has got to
represents the vast majority of affected SSL/TLS stacks.

It would have been helpful to have had more contribution earlier in the
process, we could have saved some time.

> maybe you missed the "extensions-free" part.

Possible, I'm a little slow sometimes.

On the Server Hello, they only need to generate one extension which
originates from within the TLS library itself. This should not trigger
the need to enhance the implementation's public API to add complete
generic extension support.

> Just like it is possible

I don't see a big difference in "appending a short static string to
ServerHello" and adding one extension. It shouldn't require adding
generic support where it doesn't already exist.

> magic cipher suite value, are you?

Uhhh, I didn't think so. I'm probably missing something.

Sorry, could you restate your idea just one more time concisely in a
clean thread? It can just be to me if we don't want to keep flooding the
list.

> the inclusion of an empty TLS extension in the ClientHello

My hope is that the silly MCSV (magic cipher suite value) C->S signaling
will eventually go away for clients that no longer need talk to
extension-ignorant servers.

We need the MCSV "hack" right now, but it would be nice to not require
it longer than necessary. Even today, some clients can count on
extension support from the servers. They shouldn't have to use the MCSV

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Dec 2009 21:43:28 +0100 (MET)

> behavior is only going to make deploying this fix slower.

In principle I agree with Nasko an Marsh, the fix-renego spec
should _not_ mandate any specific behaviour that has been
previously undefined.

I'm still convinced that the underlying security risk should be
described clearly in the Security Considerations of this document, but
leave it up to implementations (TLS and apps) how to address any
potential security problems in this area.

Although there is a known-safe behaviour, it is also one that is quite
restrictive, and that might be a killer to some existing scenarios.

> cause breakage, while it will work just fine in today's world. 

That sounds VERY strange.  There is absolutely _NO_ requirement
that a TLS implementation limits the lifetime of a TLS session
to the lifetime of the certificates that were used to establish
this session!

This only makes sense in environments where (a) the peers keep
an eye on the certificate lifetime when using a TLS session
and requring renegotiation when that expires and (b) a real
app-level re-authentication is performed for every re-neogotiation.

There are application and protocol designs where this is not done
and can not be done.  A certificate path validation that a
TLS implementation might be doing fairly automatically is
definitely _not_ a sufficient substitute for authentication.

"No, you can not put a lock on our office building to prevent theft.
 None of our employees are carrying keys or keycards, so they would
 not be able to enter the building anymore."

The fix is obvious and the transition period manageable.

And for the penthouse of the CEO, a security guard could be
an alternative solution...

> minimize breaking changes to the protocol.

Binary comparison of certificates is the only check that can be reliably
passed down into the TLS implementation.  Anything else will require
involvement of the application.

Therefore it is fine for a TLS implementation to offer such
functionality as an option to the application.

Mandating this to be the default, retroactively many years
back into the installed base has a significant disruptive potential
and is probably a bad idea.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 14:49:53 -0600

> "between transport layer connections"?

I realize I'm not totally indoctrinated into the IETF terminology here,
but as I read this list, it sounds like most people are thinking of the
things that get spliced between as "sessions". Sessions are the things
that are delimited by handshakes, right?

I think of a "connection" as the thing that was continuous in SSLv2 and
was split into sessions when renegotiation was added to SSLv3.

Most APIs seem to have some kind of "connection object". In many
object-oriented APIs this derives from the same interface as a plain TCP
connection.

In most usage, it seems like there's a one-to-one correspondence between
TLS connections and TCP connection, even when renegotiation and session
resumption is used.

The wording "between transport layer connections" sounds like we're
talking about TCP connections, which didn't make sense to me that two of
them would have an "in between".

Perhaps "across transport layer connections" is slightly better for that
meaning?

Even so, I'm not sure that's always necessary as it is not the essence
of the attack.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Dec 2009 13:01:05 -0800

At Wed, 02 Dec 2009 14:49:53 -0600,
> that are delimited by handshakes, right?

Unfortunately, not. Sessions can span handshakes. So, for instance,
if I form a TLS/TCP connection to a Web server, this establishes
a session, which I can then resume in a second TLS/TCP connection 
thus, reusing the keyig material. It's really unfortunate terminology.

Now, it's true that in your attack you are splicing two sessions
together (the one formed to the attacker and the one formed to the
victim client) but since the above is the context in which people
think of sessions, I think that saying it that way is probably
a bit confusing.

> was split into sessions when renegotiation was added to SSLv3.

Right, the problem is that connection-session is many-to-many.

> TLS connections and TCP connection, even when renegotiation and session

Totally.

> them would have an "in between".

Right.

> Even so, I'm not sure that's always necessary as it is not the essence

Me neither. It's all very awkward to explain :(

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 16:14:17 -0600

Eric Rescorla wrote:
> 
> Unfortunately, not. Sessions can span handshakes.

Good point.

So the thing which is an instance of a session on a connection that is
delimited by a handshake has no name.

It is these that are spliced between in the attack and are strongly
bound by the fix.

> So, for instance,

I believe session resumption reuses the master_secret, but hopefully the
hello random data makes the key material unique.

So AFAICT, the thing that uniquely identifies these unnamed things is
the key material referred to in RFCs as
(client|server)_write_(MAC_secret|key) and the Finished.verify_data.

> Me neither. It's all very awkward to explain :(

I think this confirms my long-held belief that good names are an
essential part of the design process.

- Marsh

---

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

> dictating the library<->app interface.

There is nothing wrong with mandating certain funcationality to be made
available to the application and security-relevant events to be
made visible to the application (along with the exact position
in the application data stream where those security-relevant
events take effect).

There is a lack-of-guidance defect in all of the TLS specs
about the signaling of security-relevant events after
the completion of the initial handshake, and that should be fixed.

> bundle into this bug fix, as interesting as it will be.

I fully agree that the fix under discussion ought to be
non-disruptive to on-the-wire-interop as well as
non-disruptive to TLS<->App interop and existing usage scenarios.

But even for regular updates to the TLS protocol (e.g. TLS v1.3)
backwards-incompatible changes are likely going to be a serious
problem for the future development.

During the last 14 years, whole application architectures have
been built around SSL/TLS protected communication channels
base on the existing semantics.  So all new requirements,
even for future protocol revisions, need to take the existing
usage scenarios into account (except fundamentally flawed ones).

We're actually lucky that we can plug the renegotiation defect
so easily, because it is extremely unlikely that it has been
used as a feature in existing usage scenarios, because none
of the implementations exposed this "feature" for use by
applications.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Dec 2009 14:18:41 -0800

At Wed, 02 Dec 2009 16:14:17 -0600,
> delimited by a handshake has no name.

Afraid not. You could imagine mirroring DTLS terminology and saying
"epoch" but that's not quite what epoch means either.

> It is these that are spliced between in the attack and are strongly

Yep.

> hello random data makes the key material unique.

Yep.

> (client|server)_write_(MAC_secret|key) and the Finished.verify_data.

Yep.

> essential part of the design process.

Totally. I can't tell you how much confusion the use of "session" here
has caused, especially in view of the (now mostly obsolete) term
"session key".

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Dec 2009 23:28:41 +0100 (MET)

> delimited by a handshake has no name.

It's only a vague concept in the TLS spec.  AFAIK it is in some
places refered to as "Connection State" (rfc-5246 6.1) of which
there is a "current" and a "pending" incarnation, and describes
the parameters for the enc/mac engine at the record layer.

> hello random data makes the key material unique.

That is what the spec says how the enc/mac keys are produced.

The "cheapest" rekeying on a connection would be a renegotiation
with a session resume.  It would only re-derive session keys and
avoid the public key crypto overhead.  But that seems to be disabled
in some implementations.  It might be more difficult to process
by the event-based authentication models, since a resume during
renegotiation would not involve any processing of Certificate
and CertificateVerify handshake messages.

> essential part of the design process.

A recent feedback on my I-D requested clarification of the
terminology around TLS sessions and connections.  Similar to the
handshake terminology (initial vs. renegotiation) I can not
simply point to the official protocol spec to supply that
clarification...

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 16:34:41 -0600

>> "exactly the same" rule, so seems less desirable, but really any

I don't think "exactly the same" was meant so much as a rule as a
description.

How's this:

On an initial handshake, the MCSV is semantically equivalent to an RI
extension with a zero length renegotiated_connection field. For
renegotiating handshakes, the TLS_RENEGO_PROTECTION_REQUEST cipher suite
value MAY be sent by clients but MUST be ignored by servers.

> It is also easier

I could imagine it being a big simplification for a hardware
implementation with a "hard wired" list of cipher suite values.

- Marsh

---

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: David-Sarah Hopwood <[email-masked]>
Date: Wed, 02 Dec 2009 23:05:19 +0000

> that are delimited by handshakes, right?

Yes. "between sessions" is correct; "between connections" or
"between transport layer connections" is wrong.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Wed, 02 Dec 2009 23:08:10 +0000

David-Sarah Hopwood wrote:
> Yes.

To be more precise, sessions are delimited by *full* handshakes.

> "between sessions" is correct; "between connections" or

This is accurate.

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 02 Dec 2009 15:13:01 -0800

Right.

Right.

> (client|server)_write_(MAC_secret|key) and the Finished.verify_data.

Yes.  FWIW, NSS refers to those things collectively as the connection state,
and those keys/secrets as the "connection keys".

+1

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 17:26:29 -0600

> codify the behavior of those non-conformant servers as we try to fix this

Hold on now, is there any reasonable interpretation of
draft-ietf-tls-renegotiation which "codifies the behavior of those
non-conformant servers"?

TLS implementations have every right under current specs to send and
receive hello extensions. Higher-level protocols have the right even to
require them.

This is an urgent bug fix, not an upgrade, and as such most of us share
the goal of causing absolutely minimal disruption to existing systems.

Sometimes even perfectly-conformant clients are asked to connect to TCP
port numbers on which a few *gasp* imperfect servers are listening.
Since this sometimes results in a hung connection, the condition can
only be detected after a (relatively) long timeout.

The recognition of this reality, done purely in consideration of the end
users of this technology, does not in any way "codify the behavior of
those servers".

>> is necessary in operation today.

I agree in principle.

In this case though, it would be asking application code owners to rip
out their fallback logic. Many of them would be willing to do it of
course, but it would still fall short of our goal to engineer a fix
which is deliverable as a patch only to the TLS library.

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 02 Dec 2009 15:30:29 -0800

> 1.0 had been around for about 11 years and SSLv3 was all but dead.

I would not say that SSLv3 was "all but dead", but rather that servers that
remain intolerant of versions numbers other than 0x0300 and/or intolerant of
all hello extensions are all but dead.

> they maintained fallback reconnect logic to SSLv3.

I would not characterize the fallback logic as falling back to "SSLv3".
I would characterize it as falling back to that subset of SSLv3 that is
both intolerant of version numbers other than 0x0300 and intolerant of any
and all hello extensions.  Browser vendors do indeed maintain it, but
(I believe I can say this without fear of contradiction by any browser
vendors) they all would like to eliminate it, and would have done so by now
except for the difficulty of synchronized elimination of old browser
"features".  (The first browser to unilaterally eliminate an old feature
loses market share.)

An natural opportunity to shed this old fallback logic in a synchronized
fashion comes along rarely, and this renegotiation vulnerability appears
to be just such an opportunity.

> get out of the internetworking business.

Hear! HEAR!   Sadly, there are numerous such companies that have such
draconian penalties for engineers who make even the slightest appearance
of representing their employers in fora such as this that their engineers
just keep their heads down and try to do their work while escaping all
public notice.  This is also why so many participants here do not identify
themselves with any obvious corporate or business affiliation.  :-/

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 02 Dec 2009 15:53:50 -0800

> draft-ietf-tls-renegotiation which "codifies the behavior of those

Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF*
(rather than in addition to) the RI extension is such an attempt.
Such proposals now exist.

> receive hello extensions. Higher-level protocols have the right even to

And some server vendors believe they have every right to reject client
hellos that include any hello extensions.  They now vociferously propose
that we design the solution to the renegotiation vulnerability so that,
even after they have patched their servers for this vulnerability, their
servers can CONTINUE to reject client hellos with hello extensions.
That's the issue here.

> only be detected after a (relatively) long timeout.

Those servers MUST be patched now.  It's a simple thing to patch them to
be tolerant of (that is, to IGNORE) client hellos.  But they steadfastly
refuse.  Instead they demand that we retroactively modify the definition
of TLS to explicitly recognize and legitimize this extension-intolerant
behavior.

> users of this technology, does not in any way "codify the behavior of

If it effectively requires that new client products MUST implement fallback
to be interoperable with conformant servers, then it most certainly does
codify that behavior.

> which is deliverable as a patch only to the TLS library.

I think you've got it backwards with respect to who is asking whom about
the ripping out.  The browsers WANT to rip it out.  They want to eliminate
the latency associated with the fallback.  The attempt in some present
proposals to permanently legitimize those old servers that never ignored
unrecognized extensions tells the browsers that they can never rip it out.

It is doubly ironic that the proponents of this approach are using the
existent of fall-back and the justification for their proposal.  The
argument seems to be "We once forced browsers to fall back, and the browsers
have never removed that feature.  Now we claim the on-going
existence of that fall back amounts to on-going demand for the behavior
of our old servers.  So, the standards MUST now explicitly provide for
our servers."

Regards,
/Nelson

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 01:02:06 +0100 (MET)

> > "between transport layer connections" is wrong.

I would not call that accurate.  The lack of clear terminology in
the TLS protocol specs precludes a determination of accuracy.

Authenticating the enclosing TLS session even protects from splicing
two different "connection states (RFC-5246 6.1)" derived from the
same TLS session (identified by a TLS session ID).

Since we are going to re-authenticate the previous "connection state"
with the same information that was used to authenticate that connection
state the first time around (the verify data of the finished messages),
it might be better to define the terminology before using it to describe
the characteristics.

The TLS protocol has a notion of TLS sessions associated with
the SessionID in ClientHello and ServerHello.

TLS implementations provide to applications a very different
notion of "TLS sessions" -- associated with a "Session handle"
or "SecurityContext handle".

A renegotiation that performs a full TLS handshake results in a
seperate/distinct TLS session (as identified by TLS session ID)
at the TLS protocol level, but remains "the same" session (handle)
from an application point of view.  This has a number of security
implications, including the TLS renegotiation vulnerability and
the change-in-identity-without-being-reautenticated that is
under controversial discussion.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Dec 2009 18:07:41 -0600

> to be just such an opportunity.

But, deep down, how different is that from a hardware vendor saying to
itself "now that my customers find themselves vulnerable, I'll make a
bundle by forcing them to upgrade"?

Whether his motivation is money or logical simplicty, someone who
attempts to leverage a security bug into some kind of "opportunity"
stands the risk of being judged quite harshly by the wider world who
bought and paid for what was supposed to be working security in the
first place.

Sorry if this is getting too philosophical for the list. It seems to me
to be somewhat relevant.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 01:38:10 +0100 (MET)

> Such proposals now exist.

It is not the first of it's kind.

The first is called rfc-5246, which is at proposed standard for a year
and contains a broken TLS extensions definition called signature_algorithm,
where the Server _uses_ the extension but MUST NOT confirm its use
through ServerHello.

If you look at the original extensions definition, then MCSV combined
with a SHOULD NOT include extension RI is _well_within_ the spec:

rfc-3546:

   -  Clients typically request the use of extensions via the extended
      client hello message described in Section 2.1.

   Note that the extended server hello message is only sent in response
   to an extended client hello message.  This prevents the possibility
   that the extended server hello message could "break" existing TLS 1.0
   clients.

   Note that for all extension types (including those defined in
   future), the extension type MUST NOT appear in the extended server
   hello unless the same extension type appeared in the corresponding
   client hello.  Thus clients MUST abort the handshake if they receive
   an extension type in the extended server hello that they did not
   request in the associated (extended) client hello.

What we're doing (looking at EKRs wording) is, that we are defining
the MCSV to be "an emtpy TLS extension RI"

With this definition, we are fully covered by the intent, and even
mostly covered by the wording of the TLS extensions spec!

But given that definition, that MCSV _is_ an empty "TLS extension RI"
(one that happens to be compatible even with SSLv2 ClientHello),
then it is fairly logical to _not_ completely ignore this provision in
TLS extensions:

  There MUST NOT be more than one extension of the same type.

The common sense behind this is to prevent ambiguity.  You do _not_
want to have two extensions of the same type that might differ
in their meaning, and you definitely want to avoid interop testing
complexity.

> hellos that include any hello extensions. 

Unfortunately, implementations of SSLv3 have that right.
It was a pretty bad idea from the IETF TLS WG to never publish
an updated SSLv3 spec as an informational RFC that officially
included the forward compatibility provision.

>
> They now vociferously propose

You're barking up the wrong tree.

This is about clients that have to remain interoperable with servers
that have _NOT_ been patched yet, SSLv3 Servers, SSLv2 Servers as well
as servers that are never going to be patched.

For software vendors it is a sad fact of life that they can not
recklessly ship hotfixes that will kill existing usage scenarios
in productive environments of their customers.  In particular not
for scenarios that have been interoperating fine for so many years,
and with no substantial justification for a disruptive change.

> be tolerant of (that is, to IGNORE) client hellos.

This is completely unrealistic even for newest server under full maintenance
that you can upgrade to the most recent TLS version.

The servers and clients are all over the place and belong to thousands
of entirely different organisations and will be subject
to completely independent update schedules and extremely varying
amounts of testing/validation before upgrading productive servers.

>
> But they steadfastly refuse.  Instead they demand that we retroactively
> modify the definition of TLS to explicitly recognize and legitimize
> this extension-intolerant behavior.

How about facing the real world and real world problems for an instant?

> to be interoperable with conformant servers, then it most certainly does

You're getting it backwards again.

The fallbacks are already implemented.
It would be unwise to leave the fallbacks vulnerable to downgrade attacks,
and asking those applications that have them to remove or disable
these fallbacks is a pretty bad idea.  There's nothing wrong with
those fallbacks.  They are are real world solutions to real world
problems and they were added so that customers would accept
the _new_ browsers (otherwise they would have continued to use
the previous browsers that didn't need the fallbacks).

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 03 Dec 2009 00:58:05 +0000

Chris Newman wrote:
> 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.

That is not true. Any such middlebox would already have been broken numerous
times by browser implementors adding new cipher suites to the list that
they offer. I agree with Martin; this objection is based on a completely
implausible premise.

(BTW, I don't think "straw man" is what you meant to say.
<http://en.wikipedia.org/wiki/Straw_man>)

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

If the argument about middleboxes is simply wrong (which it is), then
this argument is also wrong. There is no need for two client->server
signalling mechanisms; it's unnecessary complexity.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Dec 2009 17:01:21 -0800

At Thu, 3 Dec 2009 01:38:10 +0100 (MET),
> where the Server _uses_ the extension but MUST NOT confirm its use

To be honest, I don't recall the discussion that led to us prohibiting
the server from sending this extension at all, however I don't believe
it was about codifying the behavior of nonconformant servers. Rather,
(and my vague memory is that Pasi proposed this text so maybe he
remembers better) it was that this was a signal from the client to the
server and there was an existing method for the server to signal its
preferences when it wanted a signature, so there didn't seem to be
much point in the server sending anything back.

Note that I'm not saying this was necessarily the best design decision
in the history of the universe, but I'm not sure why you're saying it's
broken.

-Ekr

---

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

> Such proposals now exist.

Hmm, I hadn't thought of it that way.

> hellos that include any hello extensions.

Personally, I believe I have the right to write a server app that
rejects any kind of client I want. I wouldn't claim that such a server
follows the spirit of the TLS RFCs though.

Looking through RFCs 3546, 4366 though, I can't find specific wording
which requires servers to ignore extensions on the client hello that
they don't support.

RFC 5246 says "the rules specified in [TLSEXT] require servers to ignore
extensions they do not understand."

But..
>    [TLSEXT]   Eastlake, D., 3rd, "Transport Layer Security (TLS)
>               Extensions:  Extension Definitions", Work in Progress,
>               February 2008.

> servers can CONTINUE to reject client hellos with hello extensions.

I think the goal of fixing this vulnerability (which will require
patching every client and server in the world) is already ambitious
enough that it doesn't need to take on other causes. It is also
worthwhile enough that it should specifically avoid taking on any other
causes because to do so is to risk the primary goal.

> of TLS to explicitly recognize and legitimize this extension-intolerant

Well that's quite silly of them. I can't imagine why anyone would want
to continue shipping a product which doesn't interoperate well when the
fix is so easy. (Well, I can imagine some reasons but they're all bad ones.)

> to be interoperable with conformant servers, then it most certainly does

I don't think it requires new clients to implement fallback. It just
provides for clients that choose fall back or want to to be tolerant of
extension-intolerant servers.

Just because the fix doesn't actively break something that previously
worked outside the spec doesn't mean that the spec endorses it.

> the ripping out.  The browsers WANT to rip it out.

There's more to TLS than just browsers.

The bigger problem is that nobody knows has any idea many apps would
have to be changed if we did not provide a solution for SSLv3. Nobody
knows how many connections would fail if the fix required an extension
on the initial hello.

> They want to eliminate the latency associated with the fallback.

At some point, the gain in market share from the reduced latency will be
greater than the loss due to removing the fallback.

> The attempt in some present

That is a bit ironic.

Sounds to me like there probably is some customer demand for the
fallback logic, or you would have ripped it out of your browser code
already. Maybe that demand dried up years ago and the logic is leftover
only because no one has the guts to remove it. Probably only by actually
disabling it and seeing who complains can we find out how great that
demand is.

This bug fix is not the place for that experiment.

Or perhaps you were hoping that this bug would be an external event
which forced all competing browsers to remove it, that way you wouldn't
have to be the only one to stick your neck out for this
strict-compliance principle?

This bug fix is not the time for that either.

Good news though. I've talked to developers on all the major browser
vendors now, and you all feel the same way about the fallback logic!

Quit waiting for some cataclysmic opportunity and just do it.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 02:30:45 +0100 (MET)

Eric Rescorla wrote:
> 
> At Thu, 3 Dec 2009 01:38:10 +0100 (MET), Martin Rex wrote:
> > 
> > Nelson B Bolyard wrote:
> > > > 

It breaks the negotiation architecture:
   C->S   (Extended)ClientHello
   S->C   (Extended)ServerHello

I think that this negotiation architecture is useful.

And I don't mind when MCSV is going to be the only cipher suite value
that is given the "I'm an extension" status for the forseeable future
(we do require WG consensus and IESG approval for this anyway).

What I do not like is an overly religious attitude that is against
the intention and spirit of TLS extension described by this
previously quoted statement from rfc-3546:

   Clients typically request the use of extensions via the extended
   client hello message described in Section 2.1.

Trying to avoid vagueness in a spec is OK, but the choice of very
restrictive wording in order to avoid vagueness might turn out to
be too restrictive for some real world requirements, and then
it is sometimes necessary to apply common sense and re-focus on
the intent behind a restriction and not hopelessly stick to the
words (that were chosen with a different mindset).

Too restrictive words for the "change of identities" during
renegotiation may also do a lot of harm.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 02 Dec 2009 17:35:12 -0800

> where the Server _uses_ the extension but MUST NOT confirm its use

There are other client hello extensions that are not defined to be
acknowledged by the server.  that's irrelevant.

> the MCSV to be "an emtpy TLS extension RI"

No, and EKR's spect doesn't say that.  EKR's spec says that the server
responds to the two in the same way.

> But given that definition, that MCSV _is_ an empty "TLS extension RI"

No.  Not _is_.  It is convenient to your argument to imagine that it _is_.
but it is not.

>   There MUST NOT be more than one extension of the same type.

That's right.  The set of encoded extensions may not contain more than
one of the same type.  But a cipher suite is a not an encoded extension,
even when the server chooses to respond to it as if it was.

> Unfortunately, implementations of SSLv3 have that right.

Or rather, one or two out of many still do.  The vast majority of SSL 3.0
implementations ignore all extensions, and have for at least a decade.

> included the forward compatibility provision.

The IETF TLS WG never officially published any SSLv3 spec.

> and with no substantial justification for a disruptive change.

Hmm.  So software vendors cannot discontinue SSL2 support?
Oh wait, they all DID!
And for the very reason that SSLv2 was deemed insecure.

> that you can upgrade to the most recent TLS version.

There's absolutely no need to upgrade to any newer version than the version
they already claim to support.  They just need to ignore hello extensions,
and learn to correctly negotiate whatever version they claim to support
when they receive a hello with a higher version number, just as the SSL 3.0
spec always required.

Ignoring extensions is typically a ONE LINE CHANGE.  It's typically taking
a line of code that complains if the length of the message is not exactly
equal to some computed value, and changing it to allow "greater than or
equal to".

THat fix is a MUCH smaller change than any of the rest of the change
required for the vulnerability fix, and it ansolutely eliminates all need
for so-called extensionless client hellos.  It means that ANY client that
recieves a hello with BOTH a MCSV and an RI extension can do the right thing
and not require a "fall back" just because an RI was present.

> amounts of testing/validation before upgrading productive servers.

That one line of code is going to require MUCH less testing than the rest
of the patch for this vulnerability.

> How about facing the real world and real world problems for an instant?

I am facing the real world problem: namely, servers that do not conform
for years, then later demand that standards be retroactively modified to
recognize and accept their behavior as having been right all along, and
demand that future protocol changes preserve their right to continue to
be non-conforming, thereby forcing fallback behavior on clients.

> It would be unwise to leave the fallbacks vulnerable to downgrade attacks,

If servers that are invulnerable do not require fallbacks, because they
ignore extensions, and only servers that are vulnerable require fallbacks,
then only clients that fall back are vulnerable.

---

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

> they offer. I agree with Martin; this objection is based on a completely

At PhoneFactor, some of our products do need to get in the middle of a
connection (only to enhance the security of course).

As a developer of such "middlebox" systems, I can assure you that we
fully know what kind of job we're buying for ourselves taking that
position in the protocol stream. We will look long and hard for any
other option before going the route of implementing something "heroic".
We just smile and fix it when we occasionally find our presence has
disagreed with some (usually undocumented) assumption made by an
external bit of code.

We do not complain about this. To the contrary, we believe that our
ability to make stuff work under all kinds of bizarre circumstances
gives us something of a strategic advantage.

Likewise, I sites which deploy highly-restrictive firewalls and
highly-sensitive alert systems are going to be used to tweaking them
regularly. It is a professional activity which they have specifically
requested.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Dec 2009 17:48:16 -0800

At Thu, 3 Dec 2009 02:30:45 +0100 (MET),
> I think that this negotiation architecture is useful.

Hmm... It's not clear to me that that extensions always need to be
a negotiation.

In this particular case, the extension it being used as a signal the
client's preferences and the client does not need to know that the
server acknowledges them--rather it needs to deal with (or reject)
whatever cert the server sends it, as would happen if the server
didn't understand the extension. So, I'm not clear on how having the
server send an acknowledgement in this case would be useful.

Anyway, I'm not sure that there's much point in rehashing that
decision now. I only responded to observe that I don't think this
piece of 5246 was intended to codify nonconformant behavior.

-Ekr

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 03 Dec 2009 01:56:16 +0000

> the TLS protocol specs precludes a determination of accuracy.

On reflection you're right. TLS 1.2 defines what a "session" is in
section 7, and it is not consistent with what I said above (because
there may be multiple instances of the same session).

The concept we want is precisely a "channel", as defined in the
channel bindings draft and in RFC 5056. Fortunately the TLS RFC
does not already use this term in a way that would be inconsistent
with this meaning.

The channels we want to use here are identified by the contents
of a pair of Finished messages, i.e. each Finished message pair
starts a new channel.

Right.

---

From: Michael Gray <[email-masked]>
Date: Thu, 3 Dec 2009 11:58:58 +1000

> Such proposals now exist.

IMHO there is a possibility of some very small but regrettably non zero
number of old Servers still in existence (perhaps in an internal network
doing secure LDAP) that might not be able to tolerate data following a
Client hello.  Consider if a user were to apply this security fix and
update the client code that connects to these servers in a production
environment then there is risk that the production system will stop
working.  This would most likely be due to human error in that the Servers
were not updated in conjunction with the Clients, as the user might not
know that one product update requires another product update possibly from
a different vendor, but this is how adverse events start.  In this case the
security fix has broken the security principal of ‘availability’.  IMHO the
security fix must ensure that ‘availability’ is not adversely impacted for
any SSL/TLS user, even if that number of users who might be impacted is
tiny.   Additionally, I can not see how any SSL consumer is going to be
pleased with the idea that applying a fix against a possible risk can cause
a real failure in a production environment. This risk is due to client
behavior change as a result of applying the fix.  IMHO the proposed
CipherSuite signaling method provides an operationally safe probe of Server
capability due to no change in ClientHello protocol behavior.  I would go
so far as to recommend that this method be used exclusively unless the
Client in question is already sending extensions during ClientHello, in
which case the Client should send the RI Extension instead of the
CipherSuite as it is then clear that applying this security fix and sending
the RI Extension does not result in a client behavior change.

- Mick

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 03:25:17 +0100 (MET)

Michael Gray wrote:
>                                                             I would go

I'm sorry to disagree on this particular point.
(I've indicated this to Marsh previously, but not yet replied):

If a client does not _always_ include the MCSV, it is making life
extra hard for extensions-tolerant but extensions-less SSLv3/TLSv1.0/TLSv1.1
servers that do themselves _not_ need renegotation.

An SSLv3 server that is already extensions-tolerant but does not
contain code to parse TLS extensions would have two options:

  1) insist on clients to connect with extension-less ClientHellos
     so that the necessary code changes to find the MCSV are tiny.

  2) adopt generic TLS extensions code in order to find the
     TLS extension RI among a lot of other TLS extensions.

(1) is definitely much less work code-wise, but would amount to
a recommendation to effectively become extensions-intolerant.

(2) is more work to implement (implementing 1 is still necessary, mind you)
    and creates additional complexity for interop-testing

We do *NOT* need more than one signaling mechanism, so the use of
MCSV needs to be a MUST and the use of an empty TLS extension RI
on the initial ClientHello needs to be a SHOULD NOT.

The TLS extension RI can not be blindly asserted anyway, since
it needs to be filled with very specific data on renegotiation.

The client should _ALWAYS_ include the MCSV, even when sending a
TLS extension RI that includes the verify_data from Client.Finished,
so that an updated SSLv3/TLSv1.0/TLSv1.1 server that is
extensions-tolerant but extension-less and does not implement
renegotiation can easily detect by presence of MCSV when a
updated client's renegotiation is proxied into the servers
initial handshake.

Having updated clients _always_ include MCSV is really not difficult
to implement.  And as previously mentioned, the purpose of the MCSV
is the clients desire to _not_ have his handshake be accepted for
old renegotiation with an updated server (independent of whether the
server sees or supports renegotiation).

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 03 Dec 2009 03:30:38 +0100

On Thu, 03 Dec 2009 02:19:05 +0100, Marsh Ray <[email-masked]>  
wrote:

> only because no one has the guts to remove it.

No, there is no "demand" for the fallback, as such.

It is just that our users want to be able to use the browser to access  
their websites without problem, such as to be able to go to sites like  
https://www.emigrantdirect.com/  (Try that one in Opera 8.x with TLS 1.1  
enabled; I have not investigated, but it is either reacting to TLS 1.1  
being offered, which is my guess based one the profile, as it seems to be  
using the wrong version number when checking the premaster secret, or the  
extensions; I found it while going through just a couple of dozen HTTPS  
sites whose URLs I had available).

So the "demand" has not dried up.

And for the record: I am very much in favour of all browsers removing the  
fallbacks; they add way too much overhead and complexity, and make the  
clients vulnerable to version downgrade attacks.

I may have mentioned this before, but Opera 10 is shipping with the  
ability to, through an autoupdate functionality, turn off MD5, SHA-1  
support in certificates, as well as disabling SSL v3, if/when that should  
prove necessary. Additionally: We will probably soon deploy something  
similar to disable being lenient with the renegotiation problem, and with  
the fallback.

> Probably only by actually

Which is why SSL v2 and 40/56 bit encryption didn't get disabled until  
Opera 9 (2006), since important sites were still using them while we were  
betatesting 8.0 in 2004/2005, which we discovered by disabling the  
functionality.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 03:45:06 +0100 (MET)

> betatesting 8.0 in 2004/2005, which we discovered by disabling the  

Changing behaviour in a disruptive fashion on a new product release
is OK (but often a nuisance for customers -- which is why so many
users are _not_ using the most recent version of a lot of software).
"The cutting edge is often the bleeding edge."

Sneaking anything of disruptive nature into a hotfix for an installed base
is somewhere between unwise and irresponsible and may open
a software vendor to legal liabilities in some jurisdictions.

There is a reason why most of the Office PCs in companies don't feed their
updates/hotfixes directly from WindowsUpdates, but instead from an
update server run by the local IT department of the company, which
validates that hotfix in important usage scenarios before deploying
it throughout their entire infrastructure.

None of the software that *I* use is on automatic update.
I'm sick of analyzing and reporting interop&compatibility
problems that would often occur at times when I really don't
have any resources to bother with them.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 03 Dec 2009 02:47:08 +0000

Martin Rex wrote:
>> someone wrote:
[...]
>> be tolerant of (that is, to IGNORE) client hellos.

Yes, they must.

> that you can upgrade to the most recent TLS version.

Martin, you know very well the difference between upgrading to TLS 1.2 vs
making a server TLS- and extension-tolerant, so please don't continue to
conflate them.

----

IMO, the world would be a better place if client implementors all stripped
out fallbacks for TLS- and extension-intolerance and just let any remaining
noncompliant servers break. Those servers would get fixed if anyone cared
about them, probably also patching many other exploitable security
vulnerabilities in the process.

Unfortunately, client implementors -- and in particular web browser
implementors -- are not likely to agree with me on that point. I've
had enough arguments with some of them about other security vs
backward-compatibility issues to see that they have a fundamentally
different view of these things.

As long as there are some client implementors who *perceive* workarounds
for extension-intolerance to be necessary, and as long as I and others
can't *prove* that the proportion of intolerant servers is negligable
(which is trying to prove a negative, given all the servers behind
firewalls that we can't test), then the workarounds will remain.

Therefore, the fix for the renegotiation flaw will be simpler if it
introduces no reason to use such workarounds, and if the client->server
signal can be used on all connections (including fallback connections
if the client implements them for any other reason). If the spec is
able to say that it MUST be used on all connections, then that greatly
simplifies the security analysis -- which is critical because we don't
have much time to do that analysis.

This argues for allowing *only* the magic ciphersuite for C->S signalling.
It's ugly, but it's less ugly than having multiple ways to signal the
same thing, requiring more code paths and more to go wrong.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 03 Dec 2009 03:57:55 +0000

Michael Gray wrote:
> [...] Consider if a user were to apply this security fix and
> security fix has broken the security [principle] of ‘availability’.  IMHO the
> tiny.

I don't believe any fix is possible for this vulnerability that would
guarantee not to affect availability in any cases. Availability is indeed
an important security property, but TLS rightly focusses on providing
confidentiality and integrity even if that may sometimes be at the expense
of availability.

---

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

--On December 3, 2009 0:58:05 +0000 David-Sarah Hopwood 
<[email-masked]> wrote:
> That is not true. Any such middlebox would already have been broken
> numerous times by browser implementors adding new cipher suites to the
> list that they offer. I agree with Martin; this objection is based on a
> completely implausible premise.

The purpose of such a government standard (and any middlebox which enforced 
it) is to require all the browsers to be configured with a fixed cipher 
suite list of the approved cipher suites.  As major browsers support such 
configuration (often via enterprise management tools), the default list of 
ciphers in a browser is irrelevant to the scenario.

> <http://en.wikipedia.org/wiki/Straw_man>)

I meant <http://en.wikipedia.org/wiki/Straw_man_proposal>.  Or more 
precisely, I do not know if such boxes exist, but it is reasonable to 
postulate that they do and other people on the list have so postulated.

> this argument is also wrong.

I reject that the middlebox argument is wrong.  Even if it was, it is only 
one example of a bad consequence from unpredictable misuse of a standardize 
protocol field and thus would not invalidated the argument.

> There is no need for two client->server

I have no problem with dropping the cipher suite value mechanism from the 
spec as there is no strong evidence it is necessary; that would result in a 
single symmetric negotiation mechanism; one that's using the predictable 
and standardized extensibility feature.  I can live with the cipher suite 
value as a compromise as long as we're not _required_ to misuse that 
standardized protocol field in a way that implementers could not reasonably 
anticipate.

		- Chris

---

From: Michael Gray <[email-masked]>
Date: Thu, 3 Dec 2009 17:01:25 +1000

> on the initial ClientHello needs to be a SHOULD NOT.

You make a good point and I believe such a proposition should be supported,
however I think

> " empty TLS extension RI on the initial ClientHello needs to be a SHOULD
NOT"

would be better if clarified such that the RI extension must not be sent on
the initial ClientHello unless other extensions are being sent, as we do
not want to see a Client protocol level behavior change in the initial
connect.

> updated client's renegotiation is proxied into the servers

IMHO I do not see the requirement for a Server that would be updated to
detect MSCV, but does not implement safe renegotiation. However I am not
saying that such a requirement may not exist in constrained environments or
for other reasons.

- Mick

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 02 Dec 2009 23:30:28 -0800

> ciphers in a browser is irrelevant to the scenario.

Speaking of government standards, the USG ruled back in the 1990s, even
before RFC 2246 was published, that SSL 3.0 COULD NOT be FIPS compliant
because of the ways in which MD5 and SHA1 were combined in SSL3's version of
the PRF, but that TLS 1.0 could be because its PRF worked differently.
They began to require TLS 1.0 compliance way back then.  So, I'd expect
that clients offering hellos with only version 0x0300 would already not
be passing through their middle boxes.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 03 Dec 2009 16:20:30 +0100

+1

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 13:31:21 -0600

<flameSuit state="on">
	I'm thinking this is the only big sticking point left for
	draft-ietf-tls-renegotiation?
</flameSuit>

> on the initial ClientHello needs to be a SHOULD NOT.

I for one would like to see the day (say in TLS 1.7) when we no longer
need to send the MCSV on every Client Hello. It is, after all, a hack.

In order for this to ever be possible, we need servers from the first
implementation of this patch to accept and work with either the
extension or the MCSV.

The MCSV was a concession to those who needed, on occasion, to not send
any extensions. It sounds like the great majority of servers do not
break when sent extensions.

Modern browsers are sending the SNI extension, no need for the hack
there. Let them use the MCSV only for the (sigh) fall-back logic.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 21:23:18 +0100 (MET)

> there. Let them use the MCSV only for the (sigh) fall-back logic.

Do you really want to punish _ALL_ the extensions-tolerant Servers 
that do not implement TLS extensions so far for being
extensions-tolerant?  Sounds like a pretty bad idea to me.

If you don't require the MCSV on all ClientHellos, then all
extension-tolerant servers must implement TLS extensions in order
to wade through the extensions sent by clients in order to find
an empty TLS extension RI or one that contains verify_data
from a Client.Finished message.  That applies to all implementations
of SSLv3,TLSv1.0,TLSv1.1 servers which do _not_ need renegotiation.

Extensions-intolerant are going to benefit most when they remain
extensions-intolerant, becaus then they will have to look only
for MCSV, which is minimal code.

I'm sorry, but I think such an approach would be sending
an extremely wrong message!

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 14:52:07 -0600

> extensions-tolerant?  Sounds like a pretty bad idea to me.

What are you talking about?

> to wade through the extensions sent by clients

Yes, they would need to parse the extensions rather than ignore them.
It's a 4 line 'for' loop, big deal.  They don't have to add full support
for generic extension handling to their API to do this.

> in order to find
> from a Client.Finished message.

There's no other way to supply verify_data.

> That applies to all implementations

I am not aware of any TLS implementations that do not support
renegotiation (although I'm sure they exist).

> an extremely wrong message!

Sorry, I'm not seeing the big message here.

The fix we have with requires an extension. Implementations will have to
handle it, but it's pretty minimal.

It doesn't have to be a lot of code, but even an implementation that
doesn't "do renegotiation" needs to look for the RI response in the
Server Hello.

The MCSV is just a little hack as a concession to the fact that some
clients can't always send extensions because some broken servers in the
wild give slow failures when sent extensions. It doesn't get you out of
being able to properly walk a short list of extensions.

- Marsh

---

From: Wan-Teh Chang <[email-masked]>
Date: Thu, 3 Dec 2009 13:32:25 -0800

> from a Client.Finished message.

We can do what Chris Newman suggested -- require that the
RI extension be listed first in ClientHellos -- so that servers
don't need to wade through the extensions to find RI.

Wan-Teh

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 22:37:30 +0100 (MET)

> Sorry, I'm not seeing the big message here.

*I* would really like to give a message to the maintainers of old,
extensions-intolerant servers that do not need renegotiation that
they should fix the extensions-intolerance.  That would normally
be an extremely easy and obvious one-line change to their code.

Mandating MCSV and SHOULD NOTting the empty TLS extension RI
would save *EVERYONE* 3 octets per ClientHello, btw.

But if we *NOT* mandate TLS extension RI,
then this maintainer of the old extensions-intolerant server
can either leave his server extensions-intolerant, look for
MCSV (~3 lines of code) and append a fixed 7 octet string
to ServerHello (~4 lines of code) and be done with it.

When this maintainer fixes the extensions-intolerance,
then he must not only do all of the above, but additionally
add a non-trivial >25 lines of code to wade through
TLS extensions looking for TLS extension RI and come up with
a non-trivial test scenario to test that stuff.

_NOT_ making MCSV is a REALLLLLY bad idea, because those who
maintain an old extensions-intolerant server that doesn't need
renegotiation would be ill-advised to make it extensions-tolerant.

Chastizing everyone just because it looks nicer on paper
is a pretty bad idea.

Look at the issue the other way:

Q: Can anyone save a single line of code from _NOT_ mandating MCSV?

A: No! it will require at least the same amount of code,
   and for some it will require more code in the TLS implementation,
   create two code-paths and duplicate the test-scenarios!

Q: Do we at least save bandwidth by doing so?

A  No. everyone will pay 3 octets extra on every initial ClientHello!

Can you demonstrate a substantial benefit?

> handle it, but it's pretty minimal.

You are asking people to parse data from the network that comes in
small chunks with variable length fields and embedded length fields.

I would suggest that you go through the monthly security bulletins
from Microsoft and count the hotfixes for bugs in similar parsers
(various graphics formats, Word, Excel, PPT and media-files),
to realize that "oh this is just a simple loop" might not be
a very sensible approach to implement such a parser.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 03 Dec 2009 13:44:46 -0800

> don't need to wade through the extensions to find RI.

I think that the most we can/should do is RECOMMEND that the RI
extension be first in the list.  Extensions have always been an
unordered set.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 15:43:55 -0600

> don't need to wade through the extensions to find RI.

Not good I think. That amounts to just defining it as a new fixed field
on the Hello structure.  Now you're really forcing implementors who did
it the right way to add special logic to ensure this special-case ordering.

What happens the next time an extension wants to be first?

In my experience, one will end up with the best compatibility by having
the extension randomized well over the possible orderings. The specs
could have been made to say "parties sending multiple extensions SHOULD
randomize the order in which they are sent". But somehow I doubt this
group, collectively, has the stomach for that sort of thing and I expect
to be ridiculed for suggesting it. :-)

- Marsh

---

From: Badra <[email-masked]>
Date: Thu, 3 Dec 2009 22:47:38 +0100

> don't need to wade through the extensions to find RI.

RFC5246:

    When multiple extensions of different types are present in the
    ClientHello or ServerHello messages, the extensions MAY appear in any
    order.

Badra

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Dec 2009 22:49:24 +0100 (MET)

> don't need to wade through the extensions to find RI.

I would strongly recommend AGAINST this!

TLS extensions are defined to NOT have an ordering, so such a constraint
is going to cause headaches and interop problems.  Any such requirements
will result in more code and more interop problems for everyone!
PLEASE DON'T!

Here is another example for a vaguely related interop problem:

The Certificate message is defined to contain an ordered list
of certificates.  All implementation put the EndEntity cert
in the correct posistion (first), but there are some that
make an extremely poor job about the rest (OpenSSL), because
they append whatever they receive from the "application"
and neither care about ordering, nor whether the given
certs form a chain.

No Microsoft is using CPU-intensive generic functions to sort
all certificates following the EndEntity cert so that they
build a chain with the EndEntity cert.

You will find Apache Servers out there which are using Server-Certs
from multilevel CA-hierarchies and these servers will send the
chain certificates in obvious violation of the SSL&TLS protocol
unordered.  When accessing that server with MSIE, you will likely
not notice that.  Compliant TLS clients should complain about
the defective certificate chain sent by the server.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 03 Dec 2009 22:53:56 +0100

Such requirements scares me.

What if another unrelated future document decides to put in a similar
requirement, then what should implementers do?

Recommending would be fine though.

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 16:12:05 -0600

Martin Rex wrote:
> they should fix the extensions-intolerance.

Oh some of those jokers I would really love to give a stern talking-to.

But, please, this bug fix is challenging enough, let us not complicate
it further by bundling additional motivations?

> That would normally

So freaking what?

If he's doesn't renegotiate, he's secure.

If he does renegotiate, he's still insecure and is going to get publicly
pwned and consumers will know this vendor is incompetent and market
forces will take it from there.

In either case, he's no more broken than he was before, and the net as a
whole is no worse off.

> add a non-trivial >25 lines of code to wade through

I'd say it's pretty trivial, but maybe that's because I've written a
quarter-million lines or so of that kind of code.

> a non-trivial test scenario to test that stuff.

I'll wager some combination of openssl s_cilent and/or Firefox will soon
do the trick. Nothing that esoteric.

> renegotiation would be ill-advised to make it extensions-tolerant.

You're saying not only will it not encourage them to fix it, but it will
actively discourage them from fixing it?

> Chastizing everyone just because it looks nicer on paper

I don't get this part.

>    create two code-paths and duplicate the test-scenarios!

A2: Yes, someday in the future the lines of code which send and receive
the MCSV can be joyfully deleted.

> Can you demonstrate a substantial benefit?

Yes. A consistent Hello Extension mechanism is worth it's weight in
gold. This whole discussion is solely because it was inconsistently
implemented in the first place.

Yes.

You really should meet some of these network protocol implementors some
time, they really are pretty good with the small chunks.

> a very sensible approach to implement such a parser.

I'm not saying it's fool-proof or that no one can screw it up, but if,
as part of this patch, Microsoft ships a length overrun bug in parsing
TLS hello extensions I will concede your point and buy you beer and pizza.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Dec 2009 16:14:20 -0600

On Thu, Dec 03, 2009 at 01:56:16AM +0000, David-Sarah Hopwood wrote:

[Discussion of the meaning of "session" and "connection" elided.]

> of a pair of Finished messages, i.e. each Finished message pair

As the author of RFC5056, and co-author of draft-altman-tls-channel-
bindings[*]:

+1e6

I hesitate to request any additional changes to draft-ietf-tls-
renegotiation given that the surrounding threads have been a horrible
DDoS on us all.  But if there's any way to get into it a definition of
"TLS channel" in the RFC5056 sense, it'd be great if we could.

Alternatively, perhaps draft-altman-tls-channel-bindings, which defines
(or soon will) the term ought to update RFC5246.

I'm particularly interested in hearing from the Security ADs (cc'ed) how
important they think it is that we properly define the term "TLS
channel", and what vehicle is best for that purpose.

[*] Where we've had to grapple with how best to word a definition
    of "TLS channel" -- a very painful excercise that led to Martin's
    independent re-discovery of the re-negotiation vulnerability.

Nico
--

---

From: <[email-masked]>
Date: Thu, 3 Dec 2009 17:30:27 -0500

In draft-ietf-tls-renegotiation-01.txt, in section 4 last paragraph the draft 

>alert and terminate the connection.

This implies that the cipher suite TLS_RENEGO_PROTECTION_REQUEST 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. If a 
server receives a TLS_RENEGO_PROTECTION_REQUEST cipher suite on a rehandshake 
then it merely rejects the renegotiation (by generating a "no_renegotiation" 
alert at warning level).

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Dec 2009 15:00:07 -0800

At Thu, 3 Dec 2009 17:30:27 -0500,
<[email-masked]> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (7bit)>]
> 

> >at renegotiation by such a client.

That sounds right. I'll add this to my TODO list unless someone objects.

-Ekr

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 04 Dec 2009 00:00:03 +0100

Hi,

What would have been a fix to SSL when no
extensions would be available
(and if one wouldn't care about the signaling);

On a renegotiation wouldn't  taking the two
previous finished messages and insert them
between the client and server hello
for hash calculation have solved the problem?

/PS

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 17:05:04 -0600

> for hash calculation have solved the problem?

yes

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 03 Dec 2009 15:05:28 -0800

> there. Let them use the MCSV only for the (sigh) fall-back logic.

Hear! Hear!

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 00:18:49 +0100 (MET)

> for hash calculation have solved the problem?

If it has been part of the original design of renegotiation,
that would have completely solved the problem.

But as soon as you have an installed base with this
vulnerability, you need to distinguish vulnerable from
patched, and have a need for signaling.

-Martin

And nobody would be lamenting that there could be
buggy implementations out there that would add
a finished message inserted by an attacker to the
handshake message hash and otherwise completely ignore it.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 04 Dec 2009 01:08:06 +0000

> There's no other way to supply verify_data.

On the contrary, Martin's draft supplies verify_data to the Finished
computation without putting it in an extension.

FWIW, I don't understand Martin's argument about "punishing"
extension-tolerant servers either. The reason to have only one C->S
signalling mechanism (regardless of which draft is adopted) is much
simpler than that: fewer cases => simpler protocol and less to go wrong.
No moral judgements of server implementors are required or relevant here.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 19:26:33 -0600

> computation without putting it in an extension.

Good point, I should have said what I meant "... explicitly across the
wire." Martin's proposal has many things to like about it, but I was
treating that as a separate discussion.

> simpler than that: fewer cases => simpler protocol and less to go wrong.

I won't argue with that, that is definitely an important consideration.

But keep in mind, the spec still needs to deal with all cases! It can
say "producers of this protocol element MUST set A and not B", but it
still has to document what happens if it doesn't! E.g., "Consumers MUST
check for and handle the case where A is not set by alert/terminating.
Consumers MUST also check for and handle the case where B is set by blah
blah blah."

A conscientious implementor will test these cases explicitly. We can be
sure that "freelance security researchers" will be "validating" the
implementations, too.

> No moral judgements of server implementors are required or relevant here.

It is hard to resist though. :-)

- Marsh

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 04 Dec 2009 02:27:47 +0000

Michael D'Errico wrote:
> extension be first in the list.

I don't see the point. Correct implementations would have to check
the whole list anyway (and any performance benefit of the RI
extension being first is negligable).

As others have pointed out, looping through extensions is trivial;
using language such as "wading through" misrepresents its complexity.

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 03:37:10 +0100 (MET)

> No moral judgements of server implementors are required or relevant here.

It's about who will have to add/change how much code.

The installed base looks like this:

Clients:

1.  client. no extensions, no renego

2.  client. no extensions, with renego

3.  client with extensions, no renego 

4.  client with extensions, with renego

Servers:

5.  server, extensions-intolerant, no renego

6.  server, extensions-intolerant, with renego

7.  server, no extensions, no renego

8.  server, no extensions, with renego

9.  server, with extensions, no renego

10. server, with extensions, with renego

Then you have the various interop-scenarios between clients and servers
and the three attack scenarios that you want to recognize and abort
(some of which don't apply if one or both sides do not support renego)

a.  clients initial handshake is proxied into servers renegotiation

b.  clients renegotiation is proxied into servers initial handshake

c.  clients renegotiation is proxied into servers renegotiation

The question now is: what are the minimum amount of changes that
each of the 1-10 types in the installed base will have to make
in order to implement TLS extension RI.

The question whether or not MCSV is mandatory to use for ClientHello
has an impact on the amount of code some of these have to implement.

>From the servers (5) has the least amount of work if it remains
extensions-intolerant.  (7) has much more than (5) work if there is no
MUST send MCSV.

End result: (5) has a significant _negative_ incentive to become
an updated (7).  And (7) has an incentive to become an updated (5)
if we do not mandate MCSV.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 04 Dec 2009 02:37:13 +0000

>     ClientHello or ServerHello messages, the extensions MAY appear in any

Incidentally, this is an incorrect use of RFC 2119 "MAY".
RFCs 3546 and 4366 had it right:

#   Also note that when multiple extensions of different types are
#   present in the extended client hello or the extended server hello,
#   the extensions may appear in any order.  There MUST NOT be more than
#   one extension of the same type.

MAY should only be used when "an item is truly optional"; it shouldn't
be applied indiscriminately to any case where there is an implementation
choice.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 04 Dec 2009 02:52:30 +0000

Marsh Ray wrote:
> But keep in mind, the spec still needs to deal with all cases!

It does, but that doesn't necessarily require implementations to have
extra code to handle all cases. For instance, if the spec says "servers
MUST ignore a renegotiation_info extension sent in the ClientHello", then:

 - servers do not need to include any code to implement that requirement,
   since they ignore unknown extensions anyway.

 - whether the client sends the extension or not on an initial connection
   won't have any effect on security (when talking to a correct server,
   either patched or unpatched), so there is still less to go wrong.

> It is hard to resist though. :-)

I won't argue with that :-)

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 04 Dec 2009 02:58:08 +0000

David-Sarah Hopwood wrote:
> MUST ignore a renegotiation_info extension sent in the ClientHello",

I meant, an *initial* renegotiation_info, if we are talking about Eric's
draft. (For Martin's draft it would be any renego_protection extension
in the ClientHello.)

> then:

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 03 Dec 2009 19:11:59 -0800

> using language such as "wading through" misrepresents its complexity.

If someone plans to make a device to detect the RI extension (possibly
as part of a firewall or similar), then the closer it is to the front
of the list, the less delay will be added to the processing of the
connection, and the more connections can be handled per second.  We
definitely don't want our fix to slow down the establishment of all
secure connections by any significant amount.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 23:17:17 -0600

> secure connections by any significant amount.

We are talking about iterating bits of data that generally comes in over
a network, right?

Let's say the IETF gets really creative and we end up with of 20
extensions on every Client Hello. The order is well-randomized, so the
server has to "wade through" an average of 10 extensions to find the RI.
Some of these extensions are really, really big (several KB). So big
that for half of them the beginning of the next one hasn't even been
fetched into the data cache yet.

So it's reasonable to assume that the cost will be predominated by five
cold access to slow DRAM at 200ns each. Let's see that comes to... 1 us!
Well a microsecond is nothing to sneeze at.

During this microsecond many modern CPUs can be processing bits of other
connections (that do happen to be in the data cache), so some of that
might be hidden in the total throughput. Not to mention that presumably
there will be other reasons to "wade through" the extensions like if
somebody actually wants to process one for something useful. (For
comparison, my modern CPU takes about 18 ms to do an RSA in the
handshake, but I know dedicated hardware is much much faster).

Well, we don't know how long the device takes to process a handshake
without extensions, so it's hard to say what impact randomized ordering
will have.

We do know from experience that many devices end up being network-bound
rather that CPU- or memory-access-bound. It looks like there's a
two-byte length for all extensions, which strongly implies that the
maximum extension data is 64KB. Let's assume those five memory accesses
were over 16KB of data (data that somehow didn't make it into the cache).

What speed of network is necessary to be only 10 times slower than us
wading through this morass of extensions? 16KB*8/1us/10 ... I get about
13G bit/s.

So my rough estimate is that an implementation using a conventional
memory architecture could saturate a full-duplex GigE link doing nothing
but exchanging hellos loaded-out with extensions and still have 10-100x
of headroom.

This assumes of course that magic hardware makes all the other
calculations instantaneous. To the extent that assumption is false, the
overhead of wading through the extensions becomes rapidly even less
significant.

Now what happens if 90% of implementors take your recommendation and put
the RI first in the list every time (for optimum performance of course)?

A few things happen:

1. Some development group accidentally writes code that makes an
assumption that the ordering is consistent (possibly they aren't native
speakers of RFC 2119).

2. A Testing and Verification "QA" department tests their product's
interoperability with four different independent implementations. They
don't realize that all four took the recommendation on ordering, but
others that they didn't test with use some other ordering.

3. Two percent of the servers on the internet end up hanging the
connection in a slow failure mode when they get a client hello with
sub-optimally ordered extensions.

4. One of the top four major web browsers sends extensions in some
arbitrary data-dependent order. The RI extension ends up with about a
33% chance of being first. It takes a minor research effort to figure
out why 1.33% of connections end up falling back to extensionless SSLv3.

5. The hello extension mechanism gets a permanent reputation as "not
ready to require the use of on the real internet".

6. Consequently, the SNI extension is unsuitable for deployment by
shared hosting providers, so every HTTPS site needs its own IP. The
world develops an acute shortage of routable IPv4 addresses when
Twitbook buys Verisign and convinces everyone that they need a
personalized certificate for their page. Everyone switches to IPv6 (ok
now it's getting a bit far-fetched).

And last but not least:

6. Some big bloated client hello message somewhere gets processed 1
microsecond faster.

- Marsh

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 04 Dec 2009 05:50:10 +0000

> secure connections by any significant amount.

These days it is almost impossible to buy a processor that is wimpy
enough that this would add significant latency.

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 Dec 2009 08:08:18 -0800

Marsh,

While I'm sure it was fun to write your amusing response to my message,
your argument is fatally flawed because it is based on a premise that
you yourself don't even believe.  In the message I'm responding to, you
state that the people responsible for implementing the RI extension:

   A) might not be fully aware of all the nuances of TLS and
      TLS extensions, such that they may assume incorrectly
      that there is an ordering to extensions
   B) might incorrectly conclude that the assumption in (A) is
      valid, based on observations of other implementations
      they are testing against, and not based on what the specs
      actually say
   C) might ship a patched client or server that requires the
      RI extension to be in a particular location in the list,
      causing considerable problems in the field due to their
      faulty assumption and limited testing

But, when I used nearly exactly the same argument to justify the need
for our fix to be FAIL-SAFE, you had a much different view of so-called
maintenance programmers.  My argument was that the people implementing
the RI extension:

   A) might not be fully aware of all the nuances of TLS and
      TLS extensions, such that they may believe merely sending
      the old verify_data over the wire is what makes them safe
   B) might incorrectly conclude that the assumption in (A) is
      valid, based on their ability to interoperate with other
      implementations during initial handshakes and renegotiation
      handshakes, even though they never check the data
   C) might ship a patched client or server that appears to be
      patched, but yet is still completely vulnerable to MitM
      attacks since the old verify_data is not checked for accuracy

Here is how you characterized "maintenance programmers" in a message
on November 30:

     "Everyone knows that this is a critical infrastructure
      component and companies will have skilled developers
      involved in all changes and lots of testing and review.
      Don't knock "maintenance programmers", they know better
      what can go wrong than the original implementors."

I'm sorry but you can not choose when you believe what you said in this
old message and when you believe what you said in yesterday's message.

In order to believe both of these conflicting characterizations, they
would have to be:

   A) smart enough to know that they need to check the verify_data
      sent in the RI extension
   B) not smart enough to realize that extensions are not ordered
   C) smart enough to create test cases where the verify_data is
      incorrect
   D) not smart enough to create test cases where the RI extension
      is not first in the list

I think instead, you have made a pretty good argument for the need for
our fix to be fail-safe!

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 Dec 2009 09:06:14 -0800

Clarification:  The quote I used from Marsh was not arguing against a
fail-safe approach, but the complexity of parsing the RI extension.

Nevertheless, my conclusion is the same:  you can not hold two conflicting
views and pull out the one that supports your current argument.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 Dec 2009 12:23:05 -0600

Michael D'Errico wrote:
> Marsh,
> 
> While I'm sure it was fun to write your amusing response to my
> message, your argument is fatally flawed because it is based on a
> premise that you yourself don't even believe.

I'm glad you liked it. It wasn't meant to be a rigorous argument, just a
probable scenario based on past experiences. However, I think I can
adequately address the apparent inconsistencies.

> In the message I'm responding to, you state that the people
> responsible for implementing the RI extension:
> 
> A) might not be fully aware of all the nuances of TLS and TLS
> extensions, such that they may assume incorrectly that there is an
> ordering to extensions B) might incorrectly conclude that the
> assumption in (A) is valid, based on observations of other
> implementations they are testing against, and not based on what the
> specs actually say

Or they might just be a bit careless, or otherwise careful but having a
bad day.

> C) might ship a patched client or server that requires the RI
> extension to be in a particular location in the list, causing
> considerable problems in the field due to their faulty assumption and
> limited testing

Yes, that can easily happen.

>  for our fix to be FAIL-SAFE, you had a much different view of
> so-called maintenance programmers.  My argument was that the people
> implementing the RI extension:
> 
> A) might not be fully aware of all the nuances of TLS and TLS
> extensions, such that they may believe merely sending the old
> verify_data over the wire is what makes them safe

Yes, that could happen if they weren't implementing the spec carefully.

> B) might incorrectly conclude that the assumption in (A) is valid,
> based on their ability to interoperate with other implementations
> during initial handshakes and renegotiation handshakes, even though
> they never check the data

Yes, that could happen if they weren't implementing the spec carefully.

> C) might ship a patched client or server that appears to be patched,
> but yet is still completely vulnerable to MitM attacks since the old
> verify_data is not checked for accuracy

Yes, that could happen if they weren't implementing the spec carefully
_and_ their testing process did not include any simulated attack (which
we should still make a tool for).

> "Everyone knows that this is a critical infrastructure component and
> companies will have skilled developers involved in all changes and
> lots of testing and review. Don't knock "maintenance programmers",
> they know better what can go wrong than the original implementors."

I agree with that, too, for conscientious implementors.

> I'm sorry but you can not choose when you believe what you said in
> this old message and when you believe what you said in yesterday's
> message.

Yesterday, we were talking about a failure mode where an implementation
ends up still having the insecure behavior it has today, even after
patching. That can be detected externally and remedied with another
patch.  This conversation is about the possibility of a small minority
of servers poisoning the well for us all.

In my experience, a really good programmer might get a project of this
scope right the first time maybe 90% of the time. Pair that with a
good test team and test plan and the success rate goes upwards of 99%.

This will be true for all of the first-rate implementations, which are
the ones that matter. They will be interop testing with each other, even
if they do it secretly. They will probably all follow your recommended
extension ordering, not so much for performance but out of conformity.

On the other hand, probably not all of TLS implementors are consistently
perfect. There is enough variation out there that we should plan for the
scenario where somebody ends up shipping something imperfect. This is
probably a rush job for some of them, some of them may be digging up old
codebases and have lost the experience with it, and there will probably
be a plain old mistake made somewhere.

My guess is that the success rate for implementors writing new
order-independent RI code when no implementations vary the order will be
comparable to the success rate we saw for ignoring extra data on client
hellos for SSLv3 and TLS 1.0 when no implementations actually were
sending any. But many implementations already have decent support for
extensions, and they might be in more of a security-careful state of
mind, so maybe it will be better.

I think the figure I proposed was 2%, could be much more or much less,
who can predict? I'm sure it won't be zero however, and it might not
take much to have a similar effect as the extra client hello data bugs
have had on the uptake of extensions in general.

> A) smart enough to know that they need to check the verify_data sent
> in the RI extension

Well, smart enough to know which specs to read and to read them.

> C) smart enough to create test cases where the verify_data is 

Hopefully there will be tool for this.

> D) not smart enough to create test cases where the RI extension is
> not first in the list

Or they're under schedule pressure and don't have "extra" time to spend
implementing a test client and server which sends them in variable
orders. Coming up with new test cases for theoretical possibilities
(e.g., none of the major implementations you interop with do it) is
always the first thing to go out the window.

The thoroughness of the test procedures is usually not decided by the
maintenance programmer, but by company management and resources.

> I think instead, you have made a pretty good argument for the need
> for our fix to be fail-safe!

Yes, the proposals involving the PRF input modifications are probably
superior in that way.

On balance, I feel the RI is adequate in design and can be deployed
significantly faster.

- Marsh

---

From: Michael Gray <[email-masked]>
Date: Sat, 5 Dec 2009 07:35:56 +1000

When considering the impact of applying this fix in certain production
environments I have identified the following issues:

      There is a possibly of legacy systems containing SSL implementations
      that are SSLv3 only and can not negotiate TLS i.e. they have no TLS
      support at all.
      There is a possibly of legacy systems containing SSL implementations
      that are TLS extensions intolerant.
      There is a possibly of SSL implementations that can negotiate TLS,
      but legacy application(s) that can not enable it or always force
      SSLv3 (domino effect).
      Changing the “on the wire” protocol version from SSLv3 to TLS could
      cause handshakes to be blocked by a variety of network
      infrastructure.

I believe an imperative for deploying this fix is ensuring that by applying
the fix no unwanted side effects occur that could break a customer
production environment and that the fix is applicable to the greatest
amount of the installed base as possible.

The following additional note in Section 4 would be useful in addressing
this concern:

Note : Clients that use either of the signaling methods MUST be prepared to
accept a Server response containing the  "renegotiation_info" extension
transmitted in a ServerHello message with the SSLv3 protocol version {
0x03, 0x00 } and MUST continue with protected renegotiations at this
protocol level.

Additionally, I believe that adding extensions in the initial ClientHello
could result in adverse customer events in some very small number of
environments that are extensions intolerant [1].  The following additional
note in Section 5 would be useful in providing guidance in mitigating this
concern:

Note :  In cases where a ClientHello protocol behavior change from not
sending extensions to sending extensions is a risk where legacy Servers may
exist that are extension intolerant then the Client MAY mitigate this risk
by sending the TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST" and SHOULD
NOT send the "renegotiation_info" extension unless the Client is sending
other extensions.

[1] The obvious answer is to upgrade the TLS Servers that are TLS extension
intolerant, but this reasoning has the following pitfalls:

   1.  These Servers might not be identified until after the Clients have
       been updated and while they are being located and updated the
       production environment could be down.
   2.  These Servers might be out of service as far as SW updates are
       concerned and unable to be updated.  E.g. the original SW vendor no
       longer exists; newer SW will no longer run on said HW; the ability
       of the vendor to build code for said environment no longer exists.
       This all means that these Servers can not be updated and will remain
       TLS extension intolerant until the customer eventually replaces
       these systems.  Additionally, experience has shown that these
       systems are likely to be vital parts of customer infrastructure that
       have been long overlooked.

- Mick Gray
- IBM

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 05 Dec 2009 22:13:31 +0000

> 0x03, 0x00 } and MUST continue with protected renegotiations at this

This is fine, although obvious.

> NOT send the "renegotiation_info" extension unless the Client is sending

Strongly opposed. There is no justification for a SHOULD NOT-level statement
insisting that clients work around bugs in nonconformant servers. (Read the
RFC 2119 definition of SHOULD NOT; it clearly doesn't apply.)

Besides, it is incorrect to not send the RI extension in cases where it
would have contained verify_data.

---

From: Martin Rex <[email-masked]>
Date: Sun, 6 Dec 2009 04:24:03 +0100 (MET)

> This is fine, although obvious.

I'm sorry, but this seems to be non-obvious to _some_ implementors.

openssl-0.9.8-stable-SNAP-20091205 seems to already contain the original proposal vom EKR.
It will _not_ look for extensions in ServerHello if the returned server_version is 0x03,0x00

ssl/s3_clnt.c:ssl3_get_server_hello()

#ifndef OPENSSL_NO_TLSEXT
    /* TLS extensions*/
    if (s->version > SSL3_VERSION && s->version != DTLS1_VERSION && s->version != DTLS1_BAD_VER)
        {
        if (!ssl_parse_serverhello_tlsext(s,&p,d,n, &al))

> RFC 2119 definition of SHOULD NOT; it clearly doesn't apply.)

I disagree.  The SHOULD NOT is perfectly ok in the described situation,
and the justification, that you risk a connection abort is more than
sufficient.  Intentionally creating interop problems is always at least a SHOULD NOT.

> would have contained verify_data.

No, it is not incorrect.  It is just that TLS extension RI can not be made
reliably interoperable with old SSLv3 servers which do renegotiate.

The "least offending" thing for a client that implements draft-tls-renegotiation-02
and is talking to an old server is to "probe" on the renegotiation handshake
also with the MCSV and determine a mismatch of the TLS extension RI data
in the ServerHello with its own notion about the status of the session&renegotiation.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Sat, 05 Dec 2009 22:19:18 -0600

(The quoting got too much for me, check archives for thread context.)

The language in the TLS 1.0 and 1.1 specs is something like:

> TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
> supporting both is easy.  TLS clients who wish to negotiate with such
> older servers SHOULD ...

Notice the conditional SHOULD there. It seems to support the view that
successful negotiation with an SSLv3 server (especially a broken one)
is not considered a MUST for a conformant TLS implementation.

What if we adapt the proposed language thusly:

Clients that wish to be compatible with the maximum number of older
servers (including SSLv3 servers not supporting TLS), SHOULD signal
using the special TLS cipher suite value rather than including an
extension on the initial Client Hello. (Note that this does not apply to
any subsequent Client Hello messages sent.) Any such client MUST be
prepared to receive in response a Server Hello message of any negotiable
version (subject to the usual rules) which contains the extension.
Clients are not required to offer support back to SSLv3, but if they do,
they MUST implement the behaviors described in this specification.

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 06 Dec 2009 16:23:20 -0800

> is not considered a MUST for a conformant TLS implementation.

Right, ESPECIALLY not a broken one.

> extension on the initial Client Hello. 

Not "rather than", but "in addition to".  "Rather than" mandates fallback.

> (Note that this does not apply to

---

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: Marsh Ray <[email-masked]>
Date: Mon, 07 Dec 2009 03:29:01 -0600

> backup plan.  Let's not pretend otherwise. 8-)

No, there's not a backup plan if you've been selling systems that depend
on TLS renegotiation for years and have a large installed base.
Particularly if you get revenue from service contracts, you can't
regress the functionality where a fix is technically possible.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Dec 2009 11:37:09 +0200

> regress the functionality where a fix is technically possible.

That's true for SSL VPNs that have an option to login with a certificate.

It's not true for all the eBusiness sites that are almost entirely based on usernames and passwords, or even for most installations of SSL VPNs, where they use either only usernames and passwords or that together with some 2-factor authentication.

By now we know that certificate authentication of HTTPS (that's about the only good case we've seen for renegotiation) is pretty rare.

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 13:24:10 +0100

Nicolas Williams wrote:

> I'm particularly interested in hearing from the Security ADs (cc'ed)
> how important they think it is that we properly define the term "TLS

Well, I think one thing we've learned here is that none of the
reasonable-looking definitions of "TLS channel" are exactly what
typical TLS libraries offer to applications (via their APIs -- and
there's some variation between APIs, too).

Also, different people seem to have somewhat different expectations
what properties such a "channel" should have. For example, if the
certificate of peer changes in renegotiation, is that just a different
certificate for the same identity, or a different identity? Does the
application need to determine which received application_data byte
corresponds to which certificate?

This may have implications on what exactly the channel in RFC5056
sense would be. Or it may not -- the questions "what kind of
abstraction TLS libraries should provide to applications" and "what
should be 'channel' in RFC5056 sense" are certainly related, but not
the same.

Either way, I don't think we need to answer the question about 
RFC5056 "channel" in draft-ietf-tls-renegotiation. Draft-altman-tls-
channel-bindings will have to say something about this, though.

Best regards,
Pasi

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Dec 2009 08:00:27 -0800

>That's true for SSL VPNs that have an option to login with a certificate.

...*and* that option is being actively used, *and* the settings cause reauthentication during the lifetime of a user session. Having tested many SSL VPNs, I strongly suspect the number of affected end users is quite small.

--Paul Hoffman, Director
--VPN Consortium

---

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

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

I support this draft.

-- 
Steve Checkoway

---

From: Steve Dispensa <[email-masked]>
Date: Mon, 07 Dec 2009 10:22:32 -0600

On 12/7/09 10:00 AM, "Paul Hoffman" <[email-masked]> wrote:
> ...*and* that option is being actively used, *and* the settings cause
> reauthentication during the lifetime of a user session. Having tested many SSL
> VPNs, I strongly suspect the number of affected end users is quite small.

That agrees with my experience, but I don't think SSL VPN's are the main
issue. There are other cases for certificates - terminal services, web
services, SSO systems, smart cards, lord knows what else. These are all
minority cases, but they're out there.

The point isn't that there's one huge use case for certificates (although
there certainly are meaningfully large implementations of some of these
technologies). Rather, the point is that client certs have been used in a
variety of deployment scenarios for quite a few years now, and, ironically,
by those who took particular care to secure their implementations
(indicating the value of what they're protecting).

Also, while it's arguable as to how useful it is, I suspect a lot of sites
out there are still running with varying cryptographic strength
requirements. This was trivially easy to repro against current Apache with a
.htaccess file.

 -Steve

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 10:37:28 -0600

> there's some variation between APIs, too).

None is a a strong word, but even if that's true: all the more reason to
add a proper definition sooner rather than later, so that implementors
will add the required APIs.

> corresponds to which certificate?

If the re-negotiation bug is fixed then I'd say that re-negotiation does
not change the channel (same as in SSHv2, which never had this bug).

If the re-negotiation bug is NOT fixed then I'd say that re-negotiation
does change the channel.

> should be 'channel' in RFC5056 sense" are certainly related, but not

If we wanted to believe that re-negotiation replaces an existing channel
with a different one then we wouldn't consider the re-negotiation bug a
bug.  Ergo I believe that RFC5056 is correct.

> channel-bindings will have to say something about this, though.

draft-altman-tls-channel-bindings must say something about this.  What
I'm asking though, is for draft-altman-tls-channel-bindings to UPDATE
RFC5246, if it is going to be the vehicle for adding a definition of TLS
channel.

Nico
--

---

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: David-Sarah Hopwood <[email-masked]>
Date: Mon, 07 Dec 2009 21:17:12 +0000

> there's some variation between APIs, too).

I would expect a definition of "TLS channel" to inform the design of
new APIs or API abstractions. I wouldn't expect it to change existing
abstractions in current APIs, except possibly those that already have
an abstraction that almost-but-not-quite corresponds to a TLS channel,
and where the change to make it exactly correspond can be done compatibly.

> corresponds to which certificate?

The abstraction of "channel" most useful for understanding the attack
and the authentication properties of TLS, is one such that every
completed handshake begins a new channel -- whether or not there are
changes in identity information, and independent of whether the
handshake is abbreviated or full.

(I was mistaken in claiming earlier that only full handshakes should
be considered to start a new channel. Any pair of Finished messages
creates a new channel identifier, and therefore should be considered
to create a new channel.)

> RFC5056 "channel" in draft-ietf-tls-renegotiation.

I disagree; the draft currently uses the term "channel" in the
Introduction without defining it. It does reference
draft-altman-tls-channel-bindings, but this isn't sufficient
to define the term because 'It is inappropriate to use
Internet-Drafts as reference material or to cite them other than
as "work in progress."'.

The draft could, however, informatively cite RFC5056. I think it
should.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 07 Dec 2009 21:32:46 +0000

> will add the required APIs.

I agree.

> If the re-negotiation bug is NOT fixed then I'd say that re-negotiation

I think this is a misunderstanding of the RFC5056 concept of "channel".
Channel binding makes one channel cryptographically dependent on another;
it does not identify them.

> bug.

Yes, we would, because:

 - the channels are not bound, and they should be (even if they are
   presented to an application as separate streams).

 - most TLS libraries present the channels as a single stream, and so
   applications using those libraries are vulnerable regardless of how
   many channel instances we should understand there to be.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 15:26:57 -0600

> and where the change to make it exactly correspond can be done compatibly.

Look at draft-altman-tls-channel-bindings.  The impact on APIs is really
rather trivial.  All APIs will have some sort of handle to a TLS
connection.  A connection is almost a channel.  From a connection you
need a way to extract the channel bindings.

Now, the only question is: is a series of connections resulting from
re-negotiations one channel?  Or is a channel == to a connection?

(Here I'm using "connection" to mean something that's barely referred by
that name in RFC5246, but which is: the state established by a TLS
handshake and the record layer messages exchanged under its protection.)

SSHv2 also does re-negotiations, but with proper binding of
re-negotiations to the prior state.  SSHv2 even has a proper unique
channel binding: SSHv2 session IDs (which are derived by hashing all
negotiation and key exchange messages).  The SSHv2 session ID does not
change even when re-negotiations occur.

>From an RFC5056 point of view, the SSHv2 view is the correct one.  The
application sets up a channel, runs some additional application-layer
authentication mechanism over that channel with channel binding to that
channel, and then proceeds.  It would be most unfortunate if after the
authentication + channel binding operation the channel could be
replaced, without the app's knowledge, with another one that might have
an MITM.

> handshake is abbreviated or full.

For understanding the attack, yes.  But see below.

> to create a new channel.)

Prior to fixing the re-negotiation vulnerability we should have
considered each negotiation as resulting in a separate channel: then
applying channel binding as an analysis tool would have made the MITM
problem instantly apparent.

Following the fix to the re-negotiation vulnerability I think we should
say that the first negotiation establishes a channel and that the
subsequent ones do not, just as in SSHv2.

> The draft could, however, informatively cite RFC5056. I think it

I don't care which I-D introduces a proper definition of "TLS channel",
but I do care to see RFC5246 updated by whichever I-D does it.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 15:37:12 -0600

> it does not identify them.

There's "channel binding" the action (this is verb-like) and "channel
bindings" the data (this is noun-like).  The data is very much like a
name for a channel:

   o  Channel bindings: [See historical note below.]

         Generally, some data that "names" a channel or one or both of
         its end-points such that if this data can be shown, at a higher
         network layer, to be the same at both ends of a channel, then
         there are no MITMs between the two end-points at that higher
         network layer.  This term is used as a noun.

(That's from RFC5056, page 5.  See also [Lampson91].)

>    presented to an application as separate streams).

Following the fix they will be!  The fact that they aren't bound *is*
the bug in re-negotiation that we're fixing.

>    many channel instances we should understand there to be.

Not really.  If the individual connections are chained by channel
binding, then the application need only make sure that they don't mix
them up (they have to anyways, in order to interop at all).  It should
suffice that the TLS implementation chained all those connection by
channel binding them as described in whatever proposed solution to the
re-neg vuln becomes the proposed standard.

Nico
--

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 07 Dec 2009 22:17:35 +0000

> handshake and the record layer messages exchanged under its protection.)

I disagree that the abstraction presented by most TLS libraries
corresponds to a connection in the above sense. They typically present
a handle to a stream that may span multiple connections in that sense.
To change this stream-handle to a connection-handle, cannot be done
without breaking renegotiation functionality, from the point of view
of existing unmodified applications that rely on that functionality.

[...]
> subsequent ones do not, just as in SSHv2.

In that case any attempt by the application to synchronously retrieve
identity information associated with the channel, may be subject to
race conditions. It is possible to just document that problem and
leave applications to deal with it, but I have little confidence that
they will do so correctly. If, OTOH, the channel abstraction is
per-handshake, then the application can rely on the identity information
remaining constant for a given channel.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 16:20:58 -0600

> of existing unmodified applications that rely on that functionality.

Fair enough, but that's good enough, provided that: a) all the
individual connections are chained by channel binding via the RI, b) a
single one of those connections is identified for providing the channel
bindings data for the application.  (I.e., the same as SSHv2.)

> remaining constant for a given channel.

See above.  No race conditions are present if you finger the initial
connection as the one to provide the channel bindings data for the
application to use.

Note that the identity information is only relevant to the
tls-server-end-point channel binding type, and then only the server's
certificate is relevant.  If the initial connection used an anon DH
cipher suite then there will be no tls-server-end-point channel bindings
data for that channel.

ID info is utterly irrelevant to the tls-unique channel binding type.

Nico
--

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 07 Dec 2009 22:46:54 +0000

>> it does not identify them.

There is an unfortunate English usage ambiguity here: I meant "identify" in
the sense of "make identical" or "equate", not in the sense of "give a name
to".

For "channel binding" I meant the gerund. Later in the post I used
"channel identifier" for the noun.

[...]
> the bug in re-negotiation that we're fixing.

Your statement above ("If we wanted to believe...") was about the pre-fix
situation.

The fact that the channels will be bound after the fix doesn't imply that
they are the same channel. In particular, they will be treated as different
channels by applications using the 'tls-unique' channel binding type in
<http://tools.ietf.org/html/draft-altman-tls-channel-bindings>.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 07 Dec 2009 22:50:46 +0000

David-Sarah Hopwood wrote:
> identity information associated with the channel [abstraction],

including the tls-unique channel binding value

> may be subject to

---

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: <[email-masked]>
Date: Tue, 8 Dec 2009 09:50:27 +0100

> Even EKR admitted that implementing the update is an insignificant

Martin: Do you agree with EKR here or not?

(I guess "the update" here means "any of the proposed variants").

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Dec 2009 14:47:41 +0100 (MET)

> (I guess "the update" here means "any of the proposed variants").

Implementing original TLS extension RI draft and my current one is about
the same amount of work (but results in double the amount of code
for TLS extensions RI draft for implementations that _already_have_
TLS extensions support, much more for those that don't).

When MCSV is implemented and special cases are addressed, then
TLS extensions RI is a little more work.

The big difference comes with testing (which any reasonable QA can
not simply ignore).  The amount of testing required for TLS extension RI
is significantly higher than it is for my approach, simply because
all the code that I added is used all the time during regular
interop tests, there are hardly any special cases in mine.

-Martin

---

From: "tom.petch" <[email-masked]>
Date: Wed, 9 Dec 2009 10:13:34 +0100

----- Original Message -----
From: "Nicolas Williams" <[email-masked]>
Sent: Monday, December 07, 2009 10:37 PM

Nico

I don't think that channel binding is necessary.  Rather, a secure channel
provides
integrity and, optionally, secrecy (as per RFC5056).  A secure channel
can change its security parameters, a new session key for example,
but when doing so, must bind cryptographically (hate that phrase, never
quite know if I really understand it) old and new together.

In fact, channel binding as defined in RFC5056 would seem to exclude
that case, so we need binding, but not channel binding.

If there is no such binding, then we may still have a 'channel', but an insecure
channel.  Do we need that concept, or is the 'secure' implicit in all
our references to channel?

[And while I am at it, read the first paragraph of
'draft-altman-tls-channel-bindings-07.txt'
and see if it refers to what it means to refer to.]

Tom Petch

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Dec 2009 02:49:23 +0100 (MET)

> cipher suite then there will be no tls-server-end-point channel bindings

Which would make inappropriate to talk of channel bindings for
secure TLS renegotiation, because secure TLS renegotiation _will_
apply to TLS sessions established with anon DH cipher suites as well.

-Martin