Subject: [TLS] Proposal for hybrid solution using most of the ideas

From: Nasko Oskov <[email-masked]>
Date: Wed, 18 Nov 2009 23:43:05 +0000

Currently, many browsers attempt to negotiate TLS with extensions, but if it fails for any reason, they re-start the negotiation without extensions (either as a TLS negotiation or an SSLv2/3) negotiation. That behavior leads to a trivial downgrade attack by a MiTM - all the MiTM has to do is fail any negotiation with the renegotiation extension present and wait for the browser to try a negotiation without it. This leads to situation where the client is unaware if there is MiTM or real server that doesn't support extensions. If we want browsers to be secure we have no choice but fixing SSLv3 somehow or disabling it entirely.

I've been reading all the ideas people have come up with and there are some good suggestions in all the mails exchanged. After discussing the various approaches with Paul Leach and passing some ideas around with Marsh Ray, we came up with a blended approach to solving the overall problem. I would like to propose a solution that uses some of the ideas brought up. 
We all agree that there are two parts to the solution - signaling and changing state to allow for detection of the attack (aka cryptographically binding the two handshakes), so the general spirit is to use single way of changing state and different signaling for TLS and SSLv3.

For SSLv3, we can use the cipher suite idea and define the magic cipher suite value that SSLv3 client will send out to the server. Based on this indicator, server knows whether to use regular running hash as it is today or use the modified running hash. The problem for SSLv3 is the signal from the server to the client. S->C signaling must be done in a handshake message preceding the Finish message, so both client and server can agree on the version of the running hash. The one dynamic field we know from experience is handled properly by implementations is the list of certificates. We can use the server Certificate message as the signal by including specially defined certificate in the list of certificates sent by the server. If the server sees the magic cipher suite, the special certificate is included at the end of the certs being sent. We can define the cert to be the smallest possible server (aka very little real data in it) and include an unique OID to ensure we don't collide with some real usage of "empty" certificate.

Here is the matrix for interop:

                 Old server                              New server
----------------------------------------------------------------------------
Old Client |       as is                 |  server detects old client on 
           |                             |  ClientHello and can interop 
           |                             |  based on config
           |                             |  
----------------------------------------------------------------------------
New Client |  detects old server         |  server detects new client on 
           | on Certificate message and  |   initial handshake  
           | can interop based on config |  client detects new server on 
           |                             |   Certificate
           |                             |  both start using the modified 
           |                             |   running hash
----------------------------------------------------------------------------

There are few ways the running hash can be modified and it seems inserting the previous Finished message into the running hash is something everyone agrees should work. Inserting it as the initial input to the new running hash is a clean approach and allows for easier logic. The only drawback is that the SSLv3 client will have to keep two hash states around until the Certificate message is received, but the client needs to keep the ClientHello around until the ServerHello is received back, so the complexity should not be much greater.

For TLS 1.0 and above, we can use this same approach with very little modification. Since we have clear signaling in the Hello messages using extensions, both client and server can detect unpatched parties and based on config either proceed or terminate. The major difference is that TLS client doesn't have to maintain two different hash states, since server signals the client and the client can make the decision whether to hash the previous Finished message into the running hash or not. As such, the extension as proposed today does not need to transmit the actual Finished messages, as they will be cached on each end. 

Overall what we achieve is:
* modifying the running hash only for renegotiations, which allows interop for cases where renego is not needed (a big portion of the traffic)
* clear signaling in TLS implementations
* backwards compatible solution for SSLv3
* both sides can interop or not with unpatched parties based on configuration
* even if both sides are lenient in behavior, they are secure as long as both of them are patched
* clients falling back from TLS to SSLv3 because of extensions compatibility will be safe

Alternatively, we can use the existing draft for TLS and the proposed solution here for SSLv3.

Nasko

P.S. The extension will have to be a "MUST" for all TLS implementations, otherwise the MiTM can downgrade to TLS without extensions and we are back at having the problem. This requires, among other things, that browser fallback logic be slightly changed. There should not be a case of sending a TLS ClientHello without the extension. If the server reacts poorly, a downgrade directly to SSLv3 plus the signaling solution should be attempted.

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 16:15:55 -0800

So you want to have two solutions, one for TLS 1.0+ and another for
SSLv3?  I'm not sure why we need two when any solution that works
for SSL will also work for TLS.

Also the Certificate message is optional, so it would cause trouble
for some cipher suites.

And even more importantly, there is only ServerHello sent when you
resume an old session!

Mike

Nasko Oskov wrote:
> For SSLv3, we can use the cipher suite idea and define the magic cipher suite value that SSLv3 client will send out to the server. Based on this indicator, server knows whether to use regular running hash as it is today or use the modified running hash. The problem for SSLv3 is the signal from the server to the client. S->C signaling must be done in a handshake message preceding the Finish message, so both client and server can agree on the version of the running hash. The one dynamic field we know from experience is handled properly by implementations is the list of certificates. We can use the server Certificate message as the signal by including specially defined certificate in the list of certificates sent by the server. If the server sees the magic cipher suite, the special certificate is included at the end of the certs being sent. We can define the cert to be the smallest possible server (aka very little real data in it) and include an unique OID to ensure we don't c
ol
>  lide with some real usage of "empty" certificate.
>

---

From: Nasko Oskov <[email-masked]>
Date: Thu, 19 Nov 2009 01:23:41 +0000

Michael D'Errico wrote:
>
>So you want to have two solutions, one for TLS 1.0+ and another for SSLv3?  
>I'm not sure why we need two when any solution that works for SSL will also work for TLS.

I do not believe the solutions that mess up with the actual protocol are
something that should be encouraged in the TLS protocol. Hence I propose at
least the running hash behavior is the same, but signaling is different. TLS
has extensions and they are perfectly designed for this purpose. I don't see
a reason not to use them. Servers that cannot handle properly extensions will 
fall back to using SSLv3.

>Also the Certificate message is optional, so it would cause trouble for some cipher suites.

Fair point.

>And even more importantly, there is only ServerHello sent when you resume an old session!

Session resumption is already secure since it uses existing crypto state as
part of the negotiation. There are no problems in that case.

Nasko

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 19 Nov 2009 02:30:14 +0100

Hello Nasko,

Let me see if I read this correctly:

  - For TLS with Extensions, use the RI extension? Is that right? Or  
another signaling extension?
  - For SSLv3/TLS without Extensions use the special cipher. Only in this  
case, or also when the Extension is used, just in case a non-Extension  
server tolerates Extension (it IS known to happen occasionally), but do  
understand the cipher?
  - If the server understand RI, it uses that
  - If it does not understand the RI, but the cipher, send the special  
certificate

Correct so far?

If so, provided that this is always done for all the Client's Hellos, also  
the first on the connection (I got an impression from your email that this  
was not required, which could cause problems for first handshakes) I think  
it should work (though some will say it is too complex, but with this kind  
of legacy issues you can't fix a problem like this in a simple way).

The reason the RI/fallback must be used on the first negotiation is, aside  
 from the MITM attack, that I as a client need to be able to tell up front  
what I am dealing with, whether to include information in the Security  
information, adjust security levels, display a warning dialog, or refuse  
to connect to an unpatched server. I can't wait for a possible  
renegotiation.

Mike was concerned about session resume, but I do not think that is a real  
issue, since we already know the parameters of the server by this time:

   - If the server is using RI, the check will be part of the Hellos
   - If the server is using the fallback, we already know that it does (it  
is part of the TLS Session information) and modify the Finished  
calculations accordingly.
   - If it is using neither, then we also know that, and does not enable  
the modified Finished calculation mode.

The S->C signaling is only needed during a full negotiation, while the  
C->S signaling is needed each Hello since the server might not want to  
resume a session.

Mike do have a point about the cipher suites that does not use  
certificates. I am not too concerned about the Anonymous ciphers (they are  
too vulnerable anyway), but there are IIRC several suites relying on  
different key exchange methods than PKI (though not supported by Opera).  
How are those going to be secured?

It might be an idea to consider writing this up a bit more formally.

On Thu, 19 Nov 2009 00:43:05 +0100, Nasko Oskov <[email-masked]>  
wrote:

> Currently, many browsers attempt to negotiate TLS with extensions, but  
> if it fails for any reason, they re-start the negotiation without  
> extensions (either as a TLS negotiation or an SSLv2/3) negotiation. That  
> behavior leads to a trivial downgrade attack by a MiTM - all the MiTM  
> has to do is fail any negotiation with the renegotiation extension  
> present and wait for the browser to try a negotiation without it. This  
> leads to situation where the client is unaware if there is MiTM or real  
> server that doesn't support extensions. If we want browsers to be secure  
> we have no choice but fixing SSLv3 somehow or disabling it entirely.
>
> I've been reading all the ideas people have come up with and there are  
> some good suggestions in all the mails exchanged. After discussing the  
> various approaches with Paul Leach and passing some ideas around with  
> Marsh Ray, we came up with a blended approach to solving the overall  
> problem. I would like to propose a solution that uses some of the ideas  
> brought up.
> We all agree that there are two parts to the solution - signaling and  
> changing state to allow for detection of the attack (aka  
> cryptographically binding the two handshakes), so the general spirit is  
> to use single way of changing state and different signaling for TLS and  
> SSLv3.
>
> For SSLv3, we can use the cipher suite idea and define the magic cipher  
> suite value that SSLv3 client will send out to the server. Based on this  
> indicator, server knows whether to use regular running hash as it is  
> today or use the modified running hash. The problem for SSLv3 is the  
> signal from the server to the client. S->C signaling must be done in a  
> handshake message preceding the Finish message, so both client and  
> server can agree on the version of the running hash. The one dynamic  
> field we know from experience is handled properly by implementations is  
> the list of certificates. We can use the server Certificate message as  
> the signal by including specially defined certificate in the list of  
> certificates sent by the server. If the server sees the magic cipher  
> suite, the special certificate is included at the end of the certs being  
> sent. We can define the cert to be the smallest possible server (aka  
> very little real data in it) and include an unique OID to ensure we  
> don't col
> There are few ways the running hash can be modified and it seems  
> inserting the previous Finished message into the running hash is  
> something everyone agrees should work. Inserting it as the initial input  
> to the new running hash is a clean approach and allows for easier logic.  
> The only drawback is that the SSLv3 client will have to keep two hash  
> states around until the Certificate message is received, but the client  
> needs to keep the ClientHello around until the ServerHello is received  
> back, so the complexity should not be much greater.
>
> For TLS 1.0 and above, we can use this same approach with very little  
> modification. Since we have clear signaling in the Hello messages using  
> extensions, both client and server can detect unpatched parties and  
> based on config either proceed or terminate. The major difference is  
> that TLS client doesn't have to maintain two different hash states,  
> since server signals the client and the client can make the decision  
> whether to hash the previous Finished message into the running hash or  
> not. As such, the extension as proposed today does not need to transmit  
> the actual Finished messages, as they will be cached on each end.
>
> * modifying the running hash only for renegotiations, which allows  
> interop for cases where renego is not needed (a big portion of the  
> traffic)
> P.S. The extension will have to be a "MUST" for all TLS implementations,  
> otherwise the MiTM can downgrade to TLS without extensions and we are  
> back at having the problem. This requires, among other things, that  
> browser fallback logic be slightly changed. There should not be a case  
> of sending a TLS ClientHello without the extension. If the server reacts  
> poorly, a downgrade directly to SSLv3 plus the signaling solution should  
> be attempted.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
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: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 18:08:10 -0800

> part of the negotiation. There are no problems in that case.

I don't agree -- session resumption is orthogonal to renegotiation, at
least in my own code.  A MITM could exploit that.  This is one part of
RI that I agree with.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 04:10:20 +0000

Nasko Oskov wrote:
> Currently, many browsers attempt to negotiate TLS with extensions, but if it fails
> for any reason, they re-start the negotiation without extensions (either as a TLS
> negotiation or an SSLv2/3) negotiation. That behavior leads to a trivial downgrade
> attack by a MiTM - all the MiTM has to do is fail any negotiation with the
> renegotiation extension present and wait for the browser to try a negotiation
> without it. This leads to situation where the client is unaware if there is MiTM
> or real server that doesn't support extensions. If we want browsers to be secure

In the RI proposal, if the client doesn't fall back on a renegotiating
handshake, then there is no downgrade attack.

Falling back to SSLv3 on a renegotiating handshake is not necessary,
because the server needs to be patched in order for a renegotiating
handshake to succeed. If it is patched, then it is TLS- and
extension-tolerant.

We *want* renegotiating handshakes with unpatched servers to fail. That is
not an interoperability bug; it's a security feature.

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

---

From: Steve Dispensa <[email-masked]>
Date: Wed, 18 Nov 2009 23:29:49 -0600

>From the client's perspective, it's an initial negotiation, not a
renegotiation. 

> handshake to succeed. If it is patched, then it is TLS- and

That may be(come) true, but most browsers are currently doing fallback to
SSLv3 when things go wrong during (initial) negotiation. That code is in the
apps, not the SSL/TLS libraries.

For that to become true, you'd have to fix all the servers to handle TLS
(nontrivial in old code I understand) *AND* you'd have to get clients to
stop falling back to SSLv3. They couldn't stop falling back until the need
to fall back (i.e., broken TLS server implementations) disappears, which may
take a long time when you consider old code. It will take another long time
for browsers to stop falling back.

By the way, I'm assuming requiring SSLv3 to support the extension is a
non-starter. I realize it's conceptually straightforward to add, but we're
talking about adding a major mechanism to the protocol and requiring its use
immediately and unconditionally. The client must never send another Client
Hello without this extension... If the bad guy can influence the client not
to send the extension (e.g., by pretending to be a server that barfs on
SSLv3 extensions), and so the browser retries without the extension, he's
hosed.

I have heard from at least one implementer that requiring SSLv3 clients to
send extensions would have high potential for interoperability problems.

As long as it's possible for a MitM to cause the client to omit the
extension in any way, the extension can't help the client.

Now with all that said, I still think the right solution is to use the
extension in TLS, since it's architecturally pretty clean; lots of related
arguments have been made by others along these lines already. I just think
that it's not going to work for SSLv3, and something must be done for SSLv3,
or it must be turned off completely in clients.

So, I agree with Nasko - two mechanisms - an extension for TLS (and TLS
*never* sends another Client Hello without the extension), and an SSLv3 hack
of some sort.

 -Steve

---

From: Steve Dispensa <[email-masked]>
Date: Wed, 18 Nov 2009 23:35:07 -0600

> another signaling extension?

I think he means it more broadly: for TLS, use an extension. All TLS must
support the extension.

 -Steve

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 19 Nov 2009 08:49:01 +0100

I think the important point of this thread is that there are strong
arguments for providing a solution for SSLv3, not using extensions.

What I don't understand is the rationale for providing two solutions, when
one solution could work for all cases.

Finally, I don't like the certificate signaling solutions for reasons
mentioned. It may also disturb the efficiency of information caching
according to the cached info draft (even though that might be a minor
concern).

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Nov 2009 01:52:10 -0600

> one solution could work for all cases.

TLS can support a nice, clean, efficient solution going forward.

SSLv3 needs an ugly dirty hack, no way around it.

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 19 Nov 2009 09:10:03 +0100

> SSLv3 needs an ugly dirty hack, no way around it.

I disagree.

I think we agree that an upgraded finished calculation is not a dirty hack.
This is what future versions of TLS will use by default.

Remains then the signaling C->S and S->C client.

The RI proposal also includes the use of a magic cipher suite, so that dirty
hack is in both proposals.

Which leaves us with S->C signaling. Here I'm not sure we have exhausted all
options.

One way to approach this (and bring the proposals together) would be to use
the same updated finished calculations in both approaches and just use the
RI extension for signaling. In such case we could simply reduce this
discussion to debate different ways to accomplish signaling for various
versions of the protocol.

/Stefan

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 19 Nov 2009 00:39:55 -0800

On 2009-11-18 21:29 PST, Steve Dispensa wrote:
>> [...] the server needs to be patched in order for a renegotiating 
>> handshake to succeed. If it is patched, then it is TLS- and extension-
>> tolerant.
> 
> SSLv3 when things go wrong during (initial) negotiation. That code is in
> the apps, not the SSL/TLS libraries.
> 
> stop falling back to SSLv3. They couldn't stop falling back until the 
> need to fall back (i.e., broken TLS server implementations) disappears, 
> which may take a long time when you consider old code. It will take 
> another long time for browsers to stop falling back.

Not necessarily.  When the browser community perceives that all the old
"TLS-intolerant" (and extension intolerant) servers are all vulnerable, and
when the perception of this vulnerability rises to the point where browser
makers believe their users demand a way to ensure that they no longer
connect to vulnerable servers (and hence become vulnerable), then the
support for fall-back could end rather quickly, I believe.

If the major browser makers all agree, then it might just get cut off cold
at some point.  Otherwise, it might appear as a user configurable option,
and if/when sufficient numbers of users flip that switch, and admins of
vulnerable servers see usage drop off, servers will finally get upgraded.

> *never* sends another Client Hello without the extension), and an SSLv3 
> hack of some sort.

+1

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Nov 2009 10:47:29 +0200

> Which leaves us with S->C signaling. Here I'm not sure we have exhausted all

I've got one more.  

Change the Finished message calculation to include the old verify_data.  That's in all proposals.

I would add to that to also change the Finished message calculation in the initial negotiation, and use a single zero byte for the old verify_data, but do this for the client only.

That way, the client can attempt to calculate the Finished message in both the old and new way, and recognize if the server is patched or not.

I realize this is less than optimal, because in the normal handshake, the client's ChangeCipherSpec and Finished message precede the server's, so we can't alter the client's Finished message in the same way without breaking connectivity with un-patched servers.

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 19 Nov 2009 12:41:25 +0000

> SSLv3 needs an ugly dirty hack, no way around it.

That's would work if you are only using TLS or know a server supports TLS in
advance.

What browsers and many libraries (including OpenSSL) do in the first place is to
send an initial "version discovery" SSLv3 compatible client hello (or even
SSLv2) with the version number set to the maximum number of SSL/TLS supported.
The reply then indicates the version of SSL/TLS supported. Until that point you
don't know what the server supports. So the connection can end up talking TLS
v1.2 even though it initially sent and SSLv3 compatible client hello.

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Nov 2009 15:23:37 +0100 (MET)

> SSLv3 needs an ugly dirty hack, no way around it.

I'm sorry but you are mis-representing the facts in an unfair fashion.

Both approaches, TLS extension RI and my extension-free solution
change the existing protocol in the _exact_ same fashion from
an abstract point of view:

 -  both approaches add the verify_data of Client.Finished and
    Server.Finished into the handshake message hash directly
    after the ServerHello handshake message for renegotiation
    handshakes

 -  both approaches use the ClientHello and the ServerHello
    for signaling/negotiation

The changes only materialize in different bits-on-the-wire
and use a slightly different sequence of API calls to
achieve this.

The extension-less approach is going to be applicable to all existing
usage scenarios (even the SSLv2-compatible ClientHello I think)
and does not change the bits-on-the-wire of the renegotiation
handshake at all adds a ciphersuite ID to ClientHello and
re-purposes a single bit in the ServerHello -- it is difficult
to conceive to make this any more conservative.  The code changes
required for the extension-less approach is extremely small,
non-ambiguous and almost trivial to test for interoperability.

obvious problems of TLS extension RI:

 - adds significantly more bits-on-the-wire to initial and
   renegotiation handshakes

 - modifies the initial and renegotiation handshakes in different ways

 - is NON-interoperable with a significant amount of the installed
   base of SSLv3 _AND_ TLSv1.0 servers

 - can NOT be used in apps-level extension-less ClientHello fallbacks
   as implemented in most current Browsers

 - is vulnerable to downgrade attacks because of its incompatibilty
   with apps-level extension-less ClientHello fallback

 - can NOT be used in conservative clients that do not contain
   an apps-level extension-less ClientHello fallback

 - requires more code changes to implement than extension-less
   approach in newer codelines

 - requires _significantly_ more code changes to implement than
   extension-less approach in older codelines without TLS extensions

 - clients and servers that do not implement renegotiation at all
   need the full amount of code changes

 - significantly more complex test-scenarios, development of
   interop test tools required for reliable interop-testing,
   even for implementations that do NOT contain renegotiation.

-Martin

---

From: Nasko Oskov <[email-masked]>
Date: Thu, 19 Nov 2009 15:45:34 +0000

Stefan Santesson wrote:
>>> What I don't understand is the rationale for providing two solutions, 
>>> when one solution could work for all cases.
>> 

Agreed.

>The RI proposal also includes the use of a magic cipher suite, so that dirty hack is in both proposals.
>
>Which leaves us with S->C signaling. Here I'm not sure we have exhausted all options.

Yes, we might be missing something else. The reason I picked the Certificate
message is that it is dynamic size by default, so we don't have to alter
existing data, just append.

>versions of the protocol.

I realize I could've been more precise in my initial proposal. This is
exactly the essence of it. Finished calculations are the same across the
board, just signaling is different. TLS to use extensions, SSLv3 to use
whatever hack we agree on.

Nasko

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Nov 2009 16:30:53 +0000

> existing data, just append.

Sorry, I'm not clear on what's being proposed here. Is it:

a) embed a new flag of some sort in a CA-issued X.509 cert
b) add an additional server-generated self-signed cert containing
   a new flag of some sort
c) something else?

I think (a) would be a bad idea. Not sure about (b) either, but
at least it wouldn't bring a whole new bunch of parties to the
table (CA product vendors and service providers) when something
quick is what's needed.

Stephen.

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Nov 2009 09:08:26 -0800

> SSLv3 needs an ugly dirty hack, no way around it.

This appears to be the opposition to a solution that does not use
extensions.  That it is an "ugly dirty hack."  Here is how I think
about it:

We are in fact creating new versions of the protocol.  But not in
the sense that the existing version numbering scheme requires, i.e.
a strict linear progression from one version to the next.

We currently have 4 versions: SSLv3, TLS1.0, TLS1.1, TLS1.2.

We are in a sense creating 4 new parallel versions: SSLv3p, TLS1.0p,
TLS1.1p, and TLS1.2p (p meaning patched).

These four new versions sort of interleave into the list we already
have, thus we can't do what would normally be done to select which
version the client wants.  The extension-less approach Martin is
writing up has the client include a "magic" cipher suite in its
hello message to let the server know it is patched and can therefore
negotiate one of the new "p" versions.

If the server is unpatched, it will ignore the magic cipher suite
and continue as normal.  But if it is patched, then there needs to
be an unambiguous way to signal that it has selected a "p" version.
Using the server version in the ServerHello is a natural place to
put that.

My suggestion is to set the upper bit of the minor version field.
This provides a clear and unmistakable signal to the client, and is
completely contained within the 0x03 major version number space.  Is
it a "hack", yeah, but it's entirely reasonable.

Repurposing the Certificate message seems like WAYYYY more of a hack
than this!

This is also entirely forward-compatible.  The next published version
of TLS would be "TLS 4.0" {0x04,0x00}, which is greater than any of
the existing versions and also the "p" versions if the minor version
signals them.

Mike

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Nov 2009 18:49:02 +0100 (MET)

> >This is what future versions of TLS will use by default.

So far it is actually an upgraded handshake message hash calculation for
the renegotiation handshake.  TLS extension RI uses two extra layers
of wrapping

ExtendenServerHello(
   TLS-extension-RI(
      previous.Client.Finished.verify_data
      | previousServer.Finished.verify_data
   )
)

where as I'm prefering a more environmentalist approach, adding
the verify_data of the previous Client.Finished and Server.Finished
directly to the handshake message hash without any gift wrapping.

> existing data, just append.

To me that feels very wrong to use the Certificate message.
I'm convinced that it should go into the ServerHello.  I'm not
questioning that ServerHello is the correct place for all of the
cryptographic parameters _and_ the TLS extensions.

The Certificate message is not part of TLS handshakes with
server-anonymous ciphersuites and it is equally missing on
TLS session resume handshakes and I _really_ want to have
the server signal on each and every TLS handshake!

I would not even try to think about justifications why it might
be OK to omit it on some of the handshakes (My intuition says,
this is going to come back at us one way or the other if we did this).

> whatever hack we agree on.

This would add the complexity of the solution and double the
interop testing scenarios.

Why use two signaling mechanism where one is perfectly sufficient?

-Martin

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 19 Nov 2009 18:05:43 +0000

> cryptographic parameters _and_ the TLS extensions.

Well in terms of implementation and overhead I'd prefer that the client knows as
soon as possible which method to use. The need to maintain two hash contexts (or
cache some potentially long handshake messages) and always throwing one away is
IMHO not trivial.

Steve.

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Nov 2009 19:45:39 +0100 (MET)

Nasko Oskov wrote:
> Session resumption is already secure since it uses existing crypto state
> as part of the negotiation. There are no problems in that case.

I'm confused by the latter.  It doesn't sound right.

A resumed TLS session can certainly be reneogitated later, and
of course, we neither a TLS session resume to be proxied into
the reneogitation of a server, nor do we want a TLS renegotiation
on a resumes session to be unprotected/insecure like in the past.

Althouh TLS session resume seems to have been disabled during renegotiation
by at last some implementations, it would actually the first choice
if all that the client wants to do is rekeying (huge data transfers
an only RC4 or 3DES ciphersuites), because it would be the most
efficient.

TLS session resume avoids the PKI crypto overhead of the full handshake,
_but_ will derive new session keys from the master secret of the cached
session plus ClientHello.Random and ServerHello.Random
and reinitialize the SecurityParameters of the connection state.

A client initiating a TLS renegotiation would know whether it wants
to rekey (and would significantly benefit from a TLS session resume)
or when it wants to change the cryptographic characteristics of
the TLS session.

When the Client receives a ClientHelloRequest from the server,
then it doesn't know what the Server is trying to achieve by that.
The most common usage scenario for TLS renegotiation seems to
be delayed or on-demand authentication, and there a TLS session
resume wouldn't help.  But then, the server gets actually to
choose whether it performs a full TLS handshake or whether 
it agrees to a TLS session resume proposed by the client.

>From a technical point of view, a client proposing TLS resume on a
client-initiated TLS renegotiation is the same as disconnecting,
reconnecting and proposing TLS resume on the new connection.

-Martin

---

From: Nasko Oskov <[email-masked]>
Date: Thu, 19 Nov 2009 18:46:41 +0000

>  another signaling extension?

For TLS we should always be using extensions. RI is the initial proposal
that I had, but if we are fixing SSLv3 I suggest we alter it a bit to allow
for common code between SSLv3 and TLS.

>  server tolerates Extension (it IS known to happen occasionally), but do

Ciphersuite is only used in SSLv3. I propose that if apps (mostly browsers)
fall back when connecting to TLS servers that don't tolerate extensions,
instead of falling back to TLS without extensions (insecure) they fall back
to SSLv3 (which we should be fixing too).

>  - If the server understand RI, it uses that

If the server is to use the TLS protocol, yes.

>  - If it does not understand the RI, but the cipher, send the special certificate

If the server has chosen the TLS protocol, don't use any of the workarounds
suggested, just use RI and either allow unpatched clients or not based on
configuration.

>Correct so far?

I hope that clarifies it.

>of legacy issues you can't fix a problem like this in a simple way).

Signaling (whether with extensions or not) should be present always in
initial ClientHellos.

>information, adjust security levels, display a warning dialog, or refuse to
>connect to an unpatched server. I can't wait for a possible renegotiation.

Correct. We should be signaling on initial handshaking for sure. What
changes in the renegotiation case is how the Finished message is computed.

>C->S signaling is needed each Hello since the server might not want to

What I was exploring is whether we can signal S->C in any other message.
After trying to use the Server Finished and discussing it with Marsh, I
realized that we don't prevent the attack unless we signal *before* the
server generates the Server Finished.

>different key exchange methods than PKI (though not supported by Opera).

That could very well be a problem that I might have missed.

What I might have missed to communicate is the following main ideas:

* We have to fix SSLv3 and this will require changing the Finished message
  calculation (either that or disable fallback to it, which is infeasible in
  the medum term)
* If we were to do the SSLv3 change, to minimize changes overall, the
  approach for TLS could use this change and use the extension mechanism for
  signaling only (without transporting the data).
* Certificate message could be used as S->C signaling, since it is variable
  by default, most likely intermediate devices (firewall, IDS, so on) are
  not inspecting the validity of if (I doubt firewalls do chain
  verification) and as such it is less likely to have interop issues. We
  know the endpoints will handle it properly because they will be patched. I
  am worried about devices that are not upgraded dropping messages because
  of unknown contents.

Nasko

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Nov 2009 13:02:48 -0600

> v1.2 even though it initially sent and SSLv3 compatible client hello.

So using extensions (even when both ends support TLS 1.1) would
significantly change the client hello for many current clients? Yngve of
Opera and Nelson of Mozilla had posted some connection logic that didn't
work quite like that. But now that you mention it that is what I see
from typical non-browser clients.

Back to unified SSL/TLS solutions then.

Looks like C->S signaling could be achieved back to SSLv2 with the magic
cipher suite technique.

For S->C, setting that high bit in the version field is looking not so
bad now.

RFC 4346:
> server_version
>       This field will contain the lower of that suggested by the client
>       in the client hello and the highest supported by the server.

What worries me is that a great many inspecting firewalls are going to
see that and freak out because the server is replying with a version
higher than the client.

Perhaps those nice, friendly, and helpful networking hardware and
software vendors on this list will offer some lab time to check this out?

Another possibility is bit 15 of cipher_suite, assuming there will not
be a need for 32769 different cipher suites before extensions become usable.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Nov 2009 11:16:08 -0800

Dr Stephen Henson wrote:
> soon as possible which method to use.

This is especially true for hardware.

I don't think anyone would argue that firewall/monitoring devices
will want to detect the patched status of clients and servers.
The non-extension approach to solving this problem is infinitely
better to a hardware engineer.  (I design digital hardware circuits
for fun[*] -- yes I know I'm a geek.)

The hardware for detecting a patched client is just a few lines of
Verilog code:

    wire  [7:0] session_id_len  = client_hello[34];
    wire  [7:0] first_cipher_hi = client_hello[37+session_id_len];
    wire  [7:0] first_cipher_lo = client_hello[38+session_id_len];
    wire [15:0] first_cipher    = {first_cipher_hi, first_cipher_lo};

    wire patched_client = (first_cipher == MAGIC_CIPHER_SUITE);

(I hope I got that right.)

The hardware for detecting a patched server is similarly easy:

    wire  [7:0] major_version  = server_hello[0];
    wire  [7:0] minor_version  = server_hello[1];
    wire [15:0] server_version = {major_version, minor_version};

    wire patched_server = (server_version >= 16'h0380);

This is all purely combinational logic, i.e. it is nearly instantaneous.

If our solution involves extensions or altered Certificate messages,
then the hardware becomes many orders of magnitude more difficult.  You
require "sequential logic" which means that state machines are needed
to parse through the Hello messages.  Many clock cycles will be wasted,
meaning that we will have significantly slowed down all secure Internet
traffic.

Mike

[*] see http://www.digilentinc.com (contact me off-list if interested
in this -- it has made me a much better software developer as well)

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Nov 2009 20:21:55 +0100 (MET)

> see that and freak out because the server is replying with a version

I'm somewhat more worried about breaking interop with SSL and TLS peers
than confusing inspecting firewalls.

It is the IETF that defines how TLS clients and TLS servers can negotiate
a change in protocol and consensually communicate with modified
semantics.  If they want to filter on "signatures" of known attacks,
fine, but they must not make flawed assumptions about evolvement
of network or transport-level protocols.

> software vendors on this list will offer some lab time to check this out?

Of course, if vendors/suppliers are listening in to this discussion,
it would be interesting to hear their opinion on what kind of changes
might upset their equiment!

> be a need for 32769 different cipher suites before extensions become usable.

The ciphersuite number space is dived into three ranges:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-3

So you can not just shave off one bit at one end.

Same for compression identifiers (3 ranges):

http://www.iana.org/assignments/comp-meth-ids/comp-meth-ids.xhtml

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Nov 2009 13:43:56 -0600

> than confusing inspecting firewalls.

Where that is an issue, the S->C signaling would only happen if the
client requests it.

Still, I do not like giving up the ability to spot a patched server
talking to an unpatched client. But it may not be practical after all.

> of network or transport-level protocols.

No, it's not that simple in reality.

> might upset their equiment!

I am a little disappointed that we don't get more input from vendors
discussing their real-world implementations.

OpenSSL, Microsoft, Mozilla, and Opera seem to have been the best in
this regard.

> So you can not just shave off one bit at one end.

OK, but there is a bit pattern that can be XORed or some other simple
permutation to which can encode an unambiguous signal without losing
information.

Help, is there a steganographer in the house?!

- Marsh

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 20:28:44 +0000

> From the client's perspective, it's an initial negotiation, not a

No, I was referring to handshakes that are renegotiating from the
client's perspective.

> That may be(come) true,

It is true by definition, since a TLS- or extension-intolerant server
wouldn't conform to the spec for the patch.

> but most browsers are currently doing fallback to
> (nontrivial in old code I understand)

No. Servers have to be TLS-tolerant (which later SSLv3 drafts already
required) and to handle one extension; not to support TLS.

> *AND* you'd have to get clients to stop falling back to SSLv3.

That's not correct either. Clients can continue to fall back to SSLv3
provided that they do not both fall back *and* renegotiate (from the
client's point of view) on the same handshake.

> They couldn't stop falling back until the need
> immediately and unconditionally.

There's nothing particularly difficult about adding support for one
extension to an SSLv3 server. The extensions spec does not make any
assumptions that hold only for TLS and not SSLv3.

Note that, to head off a possible misconception, we are not talking here
about clients sending extensions in ClientHellos with an SSLv3 record
version. The suggestion is that an SSLv3 server could send an extension
in response to a ClientHello with a TLS record version. This will not
cause any additional interoperability problems, and is not much more
difficult than using any other signalling mechanism.

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 19 Nov 2009 21:42:51 +0100

Michael,

I find your arguments convincing.
This seems to me as a more generic and reasonable approach than a special
server certificate.

/Stefan

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Nov 2009 12:59:05 -0800

> required) and to handle one extension; not to support TLS.

When I send extensions, I send server_name, signature_algorithms, and
possibly others.  Saying that a server only has to support one extension
is going to cause trouble.

> assumptions that hold only for TLS and not SSLv3.

There are likely ZERO SSLv3 servers that support extensions, so you're
asking them all to implement them.  That is unreasonable when an
alternative exists that doesn't require extensions.

Mike

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Nov 2009 22:23:43 +0100 (MET)

> wouldn't conform to the spec for the patch.

Mind you, extension-tolerant isn't sufficient for TLS extension RI.

MSIE8 on Windows2008 will send 4 extension already, and
TLS extension RI would be the 5th.  So you need to make sure
that you code can weed out the TLS extension RI from anywhere
within the extensions list when you're newly adding it to
a codeline that doesn't have TLS extensions support yet,
in order to be interoperable.

Asking SSLv3 implementations to improve on their extensions-intolerance
is still OK.  Requiring them to implement generic TLS extensions
is not, because it has nothing to do with the problem and is
an unnecessary complexity for the fix.

-Martin

---

From: Nasko Oskov <[email-masked]>
Date: Fri, 20 Nov 2009 00:20:58 +0000

Stephen Farrell wrote:
>> Yes, we might be missing something else. The reason I picked the 
>> Certificate message is that it is dynamic size by default, so we don't 
>> have to alter existing data, just append.
>

Yes. The idea is to have an specially defined "empty" certificate that will
indicate to the client support for the new running hash computation.

>I think (a) would be a bad idea. Not sure about (b) either, but at least it
>wouldn't bring a whole new bunch of parties to the table (CA product
>vendors and service providers) when something quick is what's needed.

(a) and (b) will be too complex of changes and unnecessary complications.

Nasko

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Nov 2009 02:29:05 +0100 (MET)

> (a) and (b) will be too complex of changes and unnecessary complications.

Somehow it seems that the discussion are diverging more and more.

Personally, I'm OK with what TLS extension RI does at an abstract level.
I just don't like how it is added into the existing protocols because
of the interop issues of TLS extensions with existing usage scenarios.

I'm getting slightly beaten up for "modifying the handshake message
hash algorithm" because it is a change of the protocol and next
I getting slightly beaten up for conveying this protocol change
in through the ProtocolVersion server_version field.

You are now proposing to put something in a list of certificates
that is not a certificate, in a handshake message that is not
sent in some of the handshakes to modify the message hash computation.

Inserting the Finished messages as the first data before ClientHello
into the handshake message hash seems problematic,
because:

  -    it doesn't work for scenarios where the client wants to use
       renegotiation for client identity protection and sends the
       next ClientHello piggy-backed on the ClientFinished message
       of the initial handshake.

  -    it is much more difficult for vendors/suppliers to offer
       a backwards interop for renegotiation for whatever reason,

if the finished messages are inserted directly following the
ServerHello handshake messages, then these two problems don't exist.

I'm going back to work on my I-D now.

-Martin

---

From: Bill Frantz <[email-masked]>
Date: Thu, 19 Nov 2009 18:13:56 -0800

>it a "hack", yeah, but it's entirely reasonable.

If I understand the minor version field correctly, there are 5 or 6 bits
that are always sent as zero by all current versions of TLS/SSL. Any of
them would be suitable as a S->C signal.

There may be advantages to using bits other than the 0x80 bit. For example,
if the 0x04 bit is available, then it could be used for the signaling
requirement, leaving 0x08 and higher available for future versions of TLS.
This approach would still leave a simple ordered compare available for
selecting the "most recent" protocol version both ends support.

Cheers - Bill

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Nov 2009 03:36:15 +0100 (MET)

> selecting the "most recent" protocol version both ends support.

I would _strongly_ prefer if the ServerHello.server_version field
would NOT be used in < or > comparisons while still carrying
the S->C signal.

The change in the handshake message hash algorithm for renegotiation
handshakes in order to provide secure renegotiation is a protocol
change that is orthogonal to the regular protocol versioning.

The signal should only be used for the network encoding and
the client should seperate the S->C signal from the protocol
version and store them in seperate variables.

In case there is another emergeny tomorrow (which I do NOT hope)
and we need to fix once again severa protocol versions into the past,
then shaving another bit may collide with such comparisons.

Otherwise people start wondering:
      is { 0x83,0x00 }  better or newer than { 0x03,0x03 } ?
   or is { 0x83,0x01 }  better or newer than { 0x03,0x04 } ?

Please, don't!

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 20 Nov 2009 04:09:43 +0000

> Mind you, extension-tolerant isn't sufficient for TLS extension RI.

I didn't say it was. What I did say, was correct and sufficient for
the point at hand.

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Nov 2009 06:01:07 +0100 (MET)

Dr Stephen Henson wrote:
> Well in terms of implementation and overhead I'd prefer that the client
> knows as soon as possible which method to use. The need to maintain two
> hash contexts (or cache some potentially long handshake messages) and
> always throwing one away is IMHO not trivial.

This is why I favour the approach with adding the verify_data
of the finished messages directly after ServerHello,
because that is where the "negotiation"/signaling is completed
both peers can determine how to proceed,  no assumptions
necessary, no keeping multiple hashes around.

-Martin

---

From: Nasko Oskov <[email-masked]>
Date: Fri, 20 Nov 2009 16:21:11 +0000

Martin Rex wrote:
>
>I'm getting slightly beaten up for "modifying the handshake message hash
>algorithm" because it is a change of the protocol and next I getting
>slightly beaten up for conveying this protocol change in through the
>ProtocolVersion server_version field.
>
>You are now proposing to put something in a list of certificates that is
>not a certificate, in a handshake message that is not sent in some of the
>handshakes to modify the message hash computation.

As far as I understand the purpose of this mailing list, it is meant to be
place for people to propose ideas and discuss them. I have proposed an idea,
it is being discussed. There are pros and cons to it. Now let's try to
either agree or disagree whether it is viable solution and move on, since we
have a problem to solve.

>Inserting the Finished messages as the first data before ClientHello into
>the handshake message hash seems problematic, because:
>

In this case it might indeed be a bit more work to implement it.

>       a backwards interop for renegotiation for whatever reason,

Backwards interop is equivalent to any other solution out there. Server will
only signal back to clients that have informed the server they are patched.
This is true for RI and your proposal for using the version number. I don't
understand why you believe it will be more difficult and there is no
specific reason you are citing. I would appreciate if you are as
constructive as in your previous point.

>if the finished messages are inserted directly following the ServerHello
>handshake messages, then these two problems don't exist.
>

Great! I'd be glad to read it.

Nasko

---

From: Chris Newman <[email-masked]>
Date: Fri, 20 Nov 2009 15:24:09 -0800

> an unnecessary complexity for the fix.

What if we require SSLv3 compatible clientHello and SSLv3 serverHello to 
list RI first and at least ignore additional extensions, waiving the 
requirement for full extension support for SSLv3-only implementations?

The we'd have only one way to advertise that the client/server is patched 
to fix the renegotiation vulnerability, but we reduce the amount of work 
necessary to fix an SSLv3-only implementation (to the point where it 
provides the level of security and renegotiate functionality that SSLv3 
claimed to provide)?

		- Chris

---

From: Martin Rex <[email-masked]>
Date: Sat, 21 Nov 2009 01:02:12 +0100 (MET)

> requirement for full extension support for SSLv3-only implementations?

I don't see how this would solve the problem.

How to you interoperate with installed base SSLv3 and TLSv1.0 that
is extensions-intolerant without being vulnerable to downgrade attacks?

The restriction that this extension must be first comes very unnatural
and is bound to result in interop problems, because it will usually
not show up in tests that have generic TLS extension functionality.
It seems like dangerous design.

Maybe this explains the abstract problem better:

If you look at the two different possibilities to get the verify_data
into the handshake message hash on renegotiation:

   1)  put them into a handshake message and they will be hashed
       automatically

   2)  have each peer add them manually to the handshake message
       hash directly after ServerHello
 
which of the two is better engineering-wise?

Definitely (2).  (1) is incomplete and fails unsafe.

It is unlikely that if (2) was used that _everyone_ would implement
it incorrectly.  If implemented incorrectly, you will get interop
problems when testing with regular old and new peers.
So this approach fails safe.

No matter how poorly you implement (1), you will always interoperate.
What is missing in (1) is the requirement, that the verify_data in
the handshake messages is actually verified by the receiver!
If you have implementors that actually forget to perform
the comparison, you will NEVER notice this in interop-tests.
You will actually need to build yourself attack-tools to make
sure that your implementations actually verify that data.
So approach (2) fails UNsafe. 

It is true that I did add (2) to my last proposal by including
the verify_data in the Hello.Random elements.  *I* still prefer
to call the hash function manually, because it will fail safe.

-Martin

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 21 Nov 2009 13:24:59 +0000

> from typical non-browser clients.

Just to add a point to this which hasn't really been mentioned.

The discussion of connection logic has largely been browser centric, non-browser
clients often work in a different way and the current proposal
(draft-ietf-tls-renegotiation-01.txt) can cause them significant problems.

As mentioned above an SSLv3 or even SSLv2 compatible client hello is commonly
used to determine the servers capabilities and have maximum chance of success.

Talking of "fallbacks" is all very well for browsers or libraries that have
total control over the connection and can reconnect easily. That is not always
the case. Libraries often get passed a file descriptor only. That may or may not
be a connected socket: the transport doesn't have to be over TCP/IP. The library
has to negotiate over that descriptor as best as it can. If the connection is
dropped it's game over: the library cannot automatically reconnect in general.

Reconnection can be done at the application level but if you have hundreds or
thousands of applications, some not even maintained any more that is a daunting
task (yes I'm talking about OpenSSL here). Updating a library in a way that is
transparent to as many applications as possible is far easier.

Steve.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 21 Nov 2009 08:08:06 -0800

> transparent to as many applications as possible is far easier.

I've been meaning to bring this up too.  My TLS library knows nothing of
sockets or even file descriptors.  It is just a string processor.  Above
that is my socket library, and conceivable I could create a different
class that communicates over a serial line or other connection type.

If a solution requires reconnecting, then I can not limit the changes to
just my TLS code.  My socket code would need to change too.  And most
likely applications using the socket library would also need to be changed.

This is unacceptable when there is a solution available that does not
require these extensive modifications.

Mike

---

From: "Thamilarasu Kandasamy (thamil)" <[email-masked]>
Date: Sun, 22 Nov 2009 06:49:29 +0530

Being able to verify the authenticity of the source of a message at the
earliest state of negotiation is better for many reasons.  When a
renegotiation is initiated, there is a state already, by leveraging some
info from state, we should have a way to do it.  I have the following
suggestion,

"Client and Server can keep track of the number of Change Cipher Spec
messages they have sent.  During renegotiation, client is in possession
of server's public key.  It could encrypt the count of CCS messages and
add as an extension to the ClientHello message.  Server could use this
to verify whether it receives message from the same source."

DTLS, defined in RFC4347, has a header field, epoch, that increments
with every CCS.  TLS too can keep track of CCS msgs and leverage it to
plug the gap in the authentication as exposed by this vulnerability.

Thanks
Thamil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Rex
> Sent: Friday, November 20, 2009 10:31 AM
> To: Dr Stephen Henson
> Cc: [email-masked]
> Subject: Re: [TLS] Proposal for hybrid solution using most of the
ideas
> Certificate
> > >> message is that it is dynamic size by default, so we don't have
to
> alter

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 21 Nov 2009 18:04:06 -0800

Hi Thamil,

Thanks for the suggestion, but there is a problem in that not all public
keys support encryption.  DSA keys, for example, can only be used to
verify digital signatures.  Another potential problem is if the attacker
can somehow synchronize the client and server such that their values for
the epoch match, they would continue with the handshake.

Keep the suggestions coming,

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 22 Nov 2009 04:15:31 +0000

> to verify whether it receives message from the same source."

How does including this count provide any benefit over using the
verify_data values, that act as a unique identifier for the previous
session?

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 21 Nov 2009 21:31:15 -0800

On 2009-11-21 05:24 PST, Dr Stephen Henson wrote:

> The discussion of connection logic has largely been browser centric,
> non-browser clients often work in a different way and the current
> proposal (draft-ietf-tls-renegotiation-01.txt) can cause them significant
> problems.

Where is this draft?  It's not on rfc-editor.org nor on ietf.org.
Are you referring to draft-RESCORLA-tls-renegotiation-01.txt?

---

From: Dr Stephen Henson <[email-masked]>
Date: Sun, 22 Nov 2009 12:50:37 +0000

> Are you referring to draft-RESCORLA-tls-renegotiation-01.txt?

Yes I meant the 01 version at:
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

Fallbacks aren't explicitly mentioned in the 00 draft. The whole issue of how
one can support secure renegotiation (if the server supports it) but still
connect to an unpatched SSLv3 or unpatched extension intolerant TLS server isn't
covered.

The 01 draft resolves this issue but requires fallbacks.

It has been mentioned elsewhere that the obvious fallback techniques using the
00 draft are vulnerable to downgrade attacks. If anyone has a reference to a
fallback technique that isn't vulnerable and complies to the 00 draft I'd be
interested to hear it.

Steve.

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 22 Nov 2009 13:40:16 -0800

On 2009-11-22 04:50 PST, Dr Stephen Henson wrote:
>>> proposal (draft-ietf-tls-renegotiation-01.txt) can cause them
>>> significant problems.
>> 
>> Where is this draft?  It's not on rfc-editor.org nor on ietf.org. Are
>> you referring to draft-RESCORLA-tls-renegotiation-01.txt?
>> 
> 

That draft has been superseded.  There has been a succession of 3 drafts:

draft-RESCORLA-tls-renegotiation-00.txt
draft-RESCORLA-tls-renegotiation-01.txt
    draft-IETF-tls-renegotiation-00.txt

each of which superseded the previous.

> Fallbacks aren't explicitly mentioned in the 00 draft. The whole issue of
> how one can support secure renegotiation (if the server supports it) but
> still connect to an unpatched SSLv3 or unpatched extension intolerant TLS
> server isn't covered.

Isn't it outside of scope?

The draft named IETF (which I support with some minor clarifications) seems
to address this quite directly.  It says that secure renegotiation cannot
be done with SSLv3.  It talks about clients who want to take the risk may
do it anyway.  But clearly, doing so is outside of the scope and intent of
this draft, which intent is to do things securely.

> It has been mentioned elsewhere that the obvious fallback techniques
> using the 00 draft are vulnerable to downgrade attacks. If anyone has a
> reference to a fallback technique that isn't vulnerable and complies to
> the 00 draft I'd be interested to hear it.

I believe that it is the intent of EKR's succession of drafts to NOT attempt
to create an invulnerable form of SSLv3.  Others in this list want to try to
do that with alternative proposals.

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 22 Nov 2009 13:58:03 -0800

> OpenSSL, Microsoft, Mozilla, and Opera seem to have been the best in

Just to clarify: I do not speak for Mozilla.  I speak for NSS.  NSS is
an SSL/TLS library used by many companies' products, including Mozilla
products, some server products from Sun Microsystems, and other products.

Each of those product vendors is free to choose how they use NSS.  NSS
provides many configuration variables, and each product that uses it is
free to use them as it wishes.

The "fall back" logic about which so much discussion has taken place in this
mailing list is not implemented in NSS.  It is a part of the Mozilla
browsers, outside (on top) of NSS.  It exists solely because of servers
that are intolerant of extensions (that refuse to negotiate a handshake if
ANY extension is present), and because of broken old SSL 3.0 servers that
cannot successfully negotiate SSL 3.0 when the client offers any other
version.

That fall back logic is now 11 years old.  I think it has served its useful
lifetime.  I think the purveyors of those broken non-compliant old servers
have had PLENTY of time to make their server correctly negotiate SSL 3.0
even when the client asks for TLS, and PLENTY of time to change to ignore
all hello extensions.

The browsers have not had a good reason to drop fall-back logic, until now.
But now, the newly found vulnerability in those old servers is, IMO, reason
enough for the browsers to disable that old fall back logic, and begin to
require what (IMO) they should have required a decade ago, that servers
actually do conform to the specifications to which they claim to conform,
and CORRECTLY implement protocol version negotiation, and correctly ignore
all non-recognized extensions.

I am urging Mozilla to make that very change with all due haste.  I think
they have a pivotal decision to make.  Is this vulnerability serious enough
that it warrants cutting off those old servers that remain vulnerable to it?
Or should they allow their users to continue to be vulnerable, by continuing
to fully interoperate with those old vulnerable servers?  That's their
decision to make. I hope they will at least join the discussion pretty soon.

---

From: Martin Rex <[email-masked]>
Date: Sun, 22 Nov 2009 23:21:47 +0100 (MET)

> even when the client asks for TLS, and PLENTY of time to change to ignore

I'm sorry, but I disagree.

I would like to draw your attention to TLS v1.2 RFC-5246 Appendix E.1 & E.2

There is nothing in there that gives us any justification to
kill extension-less SSLv3 ClientHellos or even SSLv2 ClientHellos
now for any of the existing imlementations of TLSv1.0, TLSv1.1 and TLSv1.2.

We may decide that for a future version of TLS, but not for any
of the TLS Versions already shipped.

Extension-less ClientHellos are neither root nor part of the vulnerability,
we definitely do not need extensions to fix this protocol defect.

It's our mess, so it is our task to clean it up.

-Martin

---

From: Dr Stephen Henson <[email-masked]>
Date: Sun, 22 Nov 2009 23:05:43 +0000

> do that with alternative proposals.

That is not my point. I'm not too bothered whether an invulnerable SSLv3 is ever
created.

I'd love it if extension intolerant servers vanished but I have to recognise
that isn't going to happen in the short term.

If you want to communicate with them it becomes necessary to perform secure
renegotiation *if possible* but (at least for the present) tolerate unpatched
extension intolerant servers. Similarly servers will have to tolerate unpatched
clients for a while too.

The problem with the draft as it stands is that AFAICS there is no way to tell
the difference between an extension intolerant server and a MITM spoofing one
with a patched server.

This gives the client the difficult choice of either never talking to extension
intolerant servers or being vulnerable to a downgrade attack. I find that choice
unacceptable when alternative suggestions do not have that limitation.

Steve.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Nov 2009 17:13:22 -0800

At Sun, 22 Nov 2009 23:05:43 +0000,
> unacceptable when alternative suggestions do not have that limitation.

Hmm... Section 4.1.1 is intended to provide precisely that feature.
In what way doesn't it work?

-Ekr

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 23 Nov 2009 01:31:17 +0000

> In what way doesn't it work?

<various assorted expletives>Argh! I'd been referring to the wrong draft, sigh
it's been a long day. I'll review that when I'm more awake.

Steve.

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 22 Nov 2009 18:00:11 -0800

On 2009-11-22 14:21 PST, Martin Rex wrote:
> Nelson B Bolyard wrote:
>> That fall back logic is now 11 years old.  I think it has served its
>> useful lifetime.  I think the purveyors of those broken non-compliant
>> old servers have had PLENTY of time to make their server correctly
>> negotiate SSL 3.0 even when the client asks for TLS, and PLENTY of time
>> to change to ignore all hello extensions.
> 

If I may summarize it, it says that, because all versions of the TLS
specification have always required that unrecognized extensions be ignored,
TLS 1.2 client may send extensions to older TLS servers without worry about
new extensions.  Protocol version negotiation will take care of the rest.

That also applies to specification compliant SSL 3.0 servers, which were
always supposed to ignore extra data in the client hellos.

> There is nothing in there that gives us any justification to kill
> extension-less SSLv3 ClientHellos or even SSLv2 ClientHellos now for any
> of the existing imlementations of TLSv1.0, TLSv1.1 and TLSv1.2.

> Extension-less ClientHellos are neither root nor part of the
> vulnerability, we definitely do not need extensions to fix this protocol
> defect.
> 

It is the duty of the TLS working group to fix the renegotiation
vulnerability for clients and servers that are already compliant to any of
the existing published RFCs for versions of TLS, and for any future
implementations that will be compliant.

Some in this list seem to demand that we also must devise a solution for
servers that never did comply to any of the specifications for any of the
versions, not even SSL 3.0, in that they did not ignore unknown hello
extensions, and/or did not properly negotiate any version of SSL/TLS in the
presence of requested versions other than 3.0.

Even now, we are hearing requests from purveyors of non-compliant
implementations who wish to remain non-compliant, but wish us to ensure
that we will henceforth define TLS standards to ensure interoperability with
their non-compliant implementations.

The failures of non-compliant implementations to interoperate with compliant
TLS implementations is not a shortcoming of the IETF TLS working group.  It
is not "bad engineering" on the part of the IETF TLS working group.  The
fact that some refuse to comply even now does not, IMO, create
a burden of duty on the IETF TLS working group to devise solutions that
can be implemented without requiring compliance in the implementations.

As a standards body, we can only provide assurances of interoperability for
implementations that comply to the specifications that we provide.  It is
not our duty nor our goal to provide guarantees of interoperability to
those implementations that have avoided compliance for over a decade.

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 22 Nov 2009 18:30:24 -0800

If you take an elitist position like the one you seem to be advocating,
you run the risk that your "pure" standard-compliant fix will be ignored
and people will come up with their own solutions.  You will quickly
become irrelevant.

If you were to ask me my opinion of what I would _like_ to be true, it
would be a rosy world where all standards are implemented correctly and
everybody's code interops with everybody else's.

But the reality is old code takes a long time to die.  That's why there
is a thing called "maintenance."  You might like to think that you can
force all of this old code to get upgraded, but that's not going to
happen.  It needs to be _patched_!

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 04:06:05 +0100 (MET)

> new extensions.  Protocol version negotiation will take care of the rest.

I read something else in that sections.
These sections describes known problems with the installed bases of
servers and gives recommendations to _compliant_ clients in order
to retain interoperability.

It is the golden rule of the IETF
"be liberal in what you accept, be conservative in what you send out"

which means that in order to achieve interoperability, _compliant_
clients should be conservative in what they send out, they may
want to choose an extenion-less SSLv3 ClientHello or maybe even
an old SSLv2 ClientHello if they do not have an app-level
fallback reconnect mechanism to followup on a failed
ClientHello with TLS extensions.

If TLS WG ignores the existence and the necessity of such fallback
re-connects, which are perfectly within the TLSv1.2 spec:

   Note: some server implementations are known to implement version
   negotiation incorrectly.  For example, there are buggy TLS 1.0
   servers that simply close the connection when the client offers a
   version newer than TLS 1.0.  Also, it is known that some servers will
   refuse the connection if any TLS extensions are included in
   ClientHello.  Interoperability with such buggy servers is a complex
   topic beyond the scope of this document, and may require multiple
   connection attempts by the client.

the a solution that does not work for those fallbacks will turn
these app-level fallbacks into downgrade security vulnerabilities.

Personally, I do not think that creating security vulnerabilities
on purpose is a good idea.

If Appendix E of rfc-5246 would contain only this one sentence:

Compliant TLS clients MUST NOT send extension-less ClientHello
handshake messages.

then you might argue that for TLSv1.2 you can ignore this problem.
But TLSv1.2 actually amounts to "MAY send extension-less ClientHello"
and btw. we actually need to fix an installed base of TLSv1.1 and TLSv1.0
and SSLv3.

No matter how you look at it.  Sending an extension-less ClientHello
is not a security problem.  Fixing the renegotiation vulnerability
in a fashion that turns perfectly spec-compliant behaviour into
a security vulnerability is a security problem in that fix.

I do not think it is a good idea to replace a large security problem
with a medium security problem just because a thorough fix
appears "slightly unaesthetical".

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 22 Nov 2009 19:06:24 -0800

> and people will come up with their own solutions.  You will quickly

The purveyors of all those old non-compliant products are desperately
afraid that the browsers will unify and decide as a group to stop supporting
fall-back for extension intolerant servers.  Then those old
servers would quickly become irrelevant.

> happen.  It needs to be _patched_!

And the very first patch it needs to to finally comply with the 13 year
old specification that requires it to ignore unknown extensions.  That's
not an upgrade.

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 22 Nov 2009 19:38:44 -0800

> servers would quickly become irrelevant.

Can you try to do that?  Get the browser vendors to all agree?  I would
applaud such a move.

> old specification that requires it to ignore unknown extensions.  That's

But with the RI proposal, that is not enough; they still would need to
add support for extensions just to close this security hole.  That is
not a simple patch.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 05:14:19 +0100 (MET)

> servers would quickly become irrelevant.

You seem to be on a different Internet than I am on.

The statistics that I've seen show that a significant amount of users
is not only several patches, but sometimes even several releases
behind in a software.

If you're going to break interoperability on the client side for
a problem that is mostly cause by the architecture of the 
server-side application, then you will increase the number
of people who are not going to use your latest-and-greatest
but connectivity-impaired update or product.

We don't know how many existing usage scenarios might break if
we were so negligent.

Now is a pretty bad time to start collecting these numbers,
and breaking interoperability on purpose is a pretty expensive
and offending way to obtain those numbers.  Such a move may
result in legal liability for those that sell software
in some legislations.

Sounds like casino engineering to me.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 23 Nov 2009 18:55:13 +1300

Michael D'Errico <[email-masked]> writes:

>sockets or even file descriptors.  It is just a string processor.  Above that
>is my socket library, and conceivable I could create a different class that
>communicates over a serial line or other connection type.

Same here.  TLS has been specified for use in rather strange environments like
industrial process control where you're moving data over nothing I'm familiar
with (the references in, for example, IEC 62351 are to industrial-comms
standards that I didn't recognise) and you not only don't have control over
the comms layer but even if you did you may be on a permanent virtual circuit
for which "drop the connecting and reconnect" doesn't make much sense.

The problem with TLS-everywhere is that it really has ended up everywhere, not
just on things that talk TCP/IP.

Peter.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 23 Nov 2009 07:44:25 +0000

> all non-recognized extensions.

I couldn't agree more. Also, I believe this issue of TLS- and
extension-intolerance has been greatly overemphasized in the
discussions so far.

There is no evidence that this kind of bug currently affects more
than a tiny minority of server implementations. Note that in
<http://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00>,
a single server/frontend implementation -- Lotus Domino WebSphere --
is implicated in four of the six examples given (A2, A3, A4, and A5).

However, WebSphere was fixed to be TLS-tolerant in version 5.0.9,
which was released no later than 2002 (the fix is mentioned here:
<https://bugzilla.mozilla.org/show_bug.cgi?id=168800#c8>).

Now, this does not exclude the possibility that WebSphere was just
a convenient example of a more widespread problem. But the
'interop-experience' draft doesn't provide any evidence of that,
and I've been unable to find any other evidence that would support it.

Consider for example the Mozilla tracking bug for TLS-intolerant
servers: <https://bugzilla.mozilla.org/show_bug.cgi?id=59321>

If we try to connect to each of those sites mentioned in that bug,
the ones that still exist *all* have certificates with domain name
mismatches. Therefore, connections to those servers are vulnerable
to a MITM attack, and it would be correct to refuse to interoperate
with them for that reason.

Note that in the case of web browsers, there are typically options
for a user to override mismatched certs and similar problems for
particular sites -- in Firefox these are called "Security Exceptions"
in the user interface. So, if implementors of a browser that already
has a fallback wanted to maintain it in order to avoid regressions
in connecting to currently working sites, one possibility would be
to allow the fallback only for sites in the security exception list.
Together with implementing the RI draft, that would eliminate the
possibility of both version downgrade attacks and renegotiation
attacks with no user warning, and it would not introduce any additional
security problem (because if a user registers an exception for a
domain name, then a MITM attack against that domain is possible anyway).

For clients that don't already have a fallback, OTOH, I can see no
good rationale for adding one. This issue should not be considered an
obstacle to solutions to the renegotiation flaw that use extensions.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 23 Nov 2009 08:16:05 +0000

Michael D'Errico wrote:
> Can you try to do that?  Get the browser vendors to all agree?

Quite possibly. But to do that, the discussion needs to pay more attention
to the actual frequency of extension-intolerance bugs, rather than assuming
that mere existence of such bugs is a show-stopper. Browser implementors
care about *how often* thinks break; they are not absolutists.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 Nov 2009 09:33:31 +0100

Could you elaborate on this?

I've looked through the SSLv3 spec and couldn't find any evidence that
support this claim.

> always supposed to ignore extra data in the client hellos.

It seems to me that the original client hello syntax was defined without
extensibility.

/Stefan

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Nov 2009 10:56:36 +0200

> servers would quickly become irrelevant.

Actually, patching servers is a lot easier than patching browsers. It's fairly easy for a server administrator to replace the necessary library (OpenSSL 0.9.8m?) with one that does TLS 1.3 and then we don't need any extensions.

But these same servers need to support all the clients out there. That includes the latest Firefox, but also the ever-prevalent IE6 on XP (with and without patches and service packs), as well as an old iMac running Mac OS 8.6 with a Mozilla browser, and various phones.

So if the browsers unify, that's great. Maybe the browsers will standardize on TLS 1.3 and we can drop support for all older versions the moment we decide that it's time to drop support for all pre-2010 browsers.  I think 2022 should do it.

In the meantime, we can't ignore that IE6 running on no-SP Windows XP.

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 23 Nov 2009 01:18:35 -0800

> I've looked through the SSLv3 spec and couldn't find any evidence that

The copy of the SSL 3.0 spec on which I've always relied is found at
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

On the top of page 24, it says:

   Forward compatibility note:
                  In the interests of forward compatibility, it is
                  permitted for a client hello message to include
                  extra data after the compression methods.  This data
                  must be included in the handshake hashes, but must
                  otherwise be ignored.

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 12:30:43 +0100

Stefan Santesson wrote:

> I think we agree that an upgraded finished calculation is not a
> dirty hack.  This is what future versions of TLS will use by
> default.
> 

Well.. IMHO the "magic cipher suite" (for client-to-server signalling)
is the less ugly part of the hack.

The uglier part is the server-to-client signalling. All the proposed
methods (new alert, new handshake message, SH.version, SH.random,
SH.session_id, SH.cipher_suite, SH.compression_method, "unsolicited"
extension, server's Finished, magic server Certificate) seem to "work"
(to some degree), but nobody can claim they're pretty.

Using TLS extensions is perhaps slightly less ugly, but has other
drawbacks (so I wouldn't dismiss the other options just because of
"ugliness").

However, it's IMHO good to recognize that when we start comparing
"ugliness", we're very much in the domain of subjective design
preferences, and the arguments are basically "it could/should be
nicer" (even though some recent emails have used phrases like "using X
would be wrong" or "X is a bad idea")

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 12:35:40 +0100

Hmm... If I want to detect the patched status of my servers, probably
running Nessus (or other vulnerability scanner -- which I'm running
anyway, if I care enough to deploy IDS) would be much simpler than 
real-time deep packet inspection of TLS handshakes. A busy site could 
do hundreds (or more) TLS handshakes per second, but I don't need 
to check the server's status hundred times a second...

And if you're running the check only N times a day, then the
hardware complexity of an implementation doesn't really matter...

(But using DPI to produce a "there's an SSL/TLS server running 
at this IP:port" list as input for Nessus could make sense.)

Best regards, 
Pasi 
(not wearing any hats)

> ext Michael D'Errico
> Sent: 19 November, 2009 21:16
> To: [email-masked]
> Subject: [TLS] The Hardware Angle
> 
> Dr Stephen Henson wrote:
> >

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 12:56:57 +0100

<wearing Area Director hat>

The duty of the TLS WG (and other IETF working groups) is to "make the
Internet work better" [RFC3935]. Since we're doing engineering, not
mathematics, we have to deal with the often messy real-world Internet,
not the Internet of axiomatic RFCs.

So deployability in real world is definitely one important issue that
the WG has to consider when fixing this vulnerability.

It's not the only important issue, and it's certainly one where
different people can legitimately have different opinions. But it's
also not something the WG can just ignore.

Best regards,
Pasi

Nelson B Bolyard wrote:
 
> vulnerability for clients and servers that are already compliant to
> any of the existing published RFCs for versions of TLS, and for any
> future implementations that will be compliant.
> 
> Some in this list seem to demand that we also must devise a solution
> for servers that never did comply to any of the specifications for
> any of the versions, not even SSL 3.0, in that they did not ignore
> unknown hello extensions, and/or did not properly negotiate any
> version of SSL/TLS in the presence of requested versions other than
> 3.0.
> 
> implementations who wish to remain non-compliant, but wish us to
> ensure that we will henceforth define TLS standards to ensure
> interoperability with their non-compliant implementations.
> 
> The failures of non-compliant implementations to interoperate with
> compliant TLS implementations is not a shortcoming of the IETF TLS
> working group.  It is not "bad engineering" on the part of the IETF
> TLS working group.  The fact that some refuse to comply even now
> does not, IMO, create a burden of duty on the IETF TLS working group
> to devise solutions that can be implemented without requiring
> compliance in the implementations.
> 
> As a standards body, we can only provide assurances of
> interoperability for implementations that comply to the
> specifications that we provide.  It is not our duty nor our goal to
> provide guarantees of interoperability to those implementations that
> have avoided compliance for over a decade.

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 19:27:43 +0100 (MET)

> It seems to me that the original client hello syntax was defined without

Looking at the available documents

http://tools.ietf.org/html/draft-freier-ssl-version3-00
http://tools.ietf.org/html/draft-freier-ssl-version3-01
http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

it seems to be evident that the original protocol design from
Netscape did *NOT* contain forward extensibility for the
ClientHello handshake message.

The document which I have been refering to as SSLv3 most of the
time (draft-ietf-tls-ssl-version3-00.txt) contains such a forward
compatibility notice -- however it was never published by the
IETF as an informational RFC.

When I looked at www.netscape.com in 2000-2002 and used their
site search, it directed me to an old version of the spec.

I did find the draft-ietf-tls-ssl-version3-00 document only from
searching the TLS mailing list archives, where the document had
been posted in its entirety.

Now, I see the following problems with this:

 - The forward interoperability provision in ClientHello was added
   when there already was a significant installed base that did
   not include the forward interoperability on a ClientHello extension

 - The TLS WG never cared to get an updated SSLv3 spec published
   and publicly available that contained the forward interoperability
   provision in ClientHello
   At that time, I-Ds were deleted from the repository after 6 month!

 - If you were searching for an SSLv3 spec at Netscape, you were
   usually directed to a pretty HTML&Postscript version of an
   older version of the spec without the forward interoperability
   provision.  URL from 2005:

http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM

 - The TLS WG defined TLS extensions long after TLSv1.0 and
   didn't do all that much since then in order to determine
   the scope of the interoperability problem and solutions to 
   improve the situation.  There were some efforts by individuals
   or vendors, but it does not seem that TLS WG saw it as a
   sufficiently interesting problem to care about.

What I think is funny here:  the first I-D from freier (12/95) contains
this:

     C.   Version 2.0 Backward Compatibility

     Version  3.0  clients that support Version 2.0 servers  must
     send Version 2.0 client hello messages [SSL-2]. Version  3.0
     servers  should accept either client hello format. The  only
     deviations  from  the  Version  2.0  specification  are  the
     ability  to specify a version with a value of three and  the
     support for more ciphering types in the CipherSpec.

     Warning:       The  ability to send Version 2.0 client hello
                    messages  will  be phased out  with  all  due
                    haste.  Implementors should make every effort
                    to  move  forward  as  quickly  as  possible.
                    Version  3.0  provides better mechanisms  for
                    transitioning to newer versions.

Compare this to TLSv1.2 RFC-5246:

   E.2.  Compatibility with SSL 2.0

   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
   version 2.0 CLIENT-HELLO messages defined in [SSL2].  The message
   MUST contain the same version number as would be used for ordinary
   ClientHello, and MUST encode the supported TLS cipher suites in the
   CIPHER-SPECS-DATA field as described below.

   Warning: The ability to send version 2.0 CLIENT-HELLO messages will
   be phased out with all due haste, since the newer ClientHello format
   provides better mechanisms for moving to newer versions and
   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.

Which essentially means that TLSv1.2 still plans to phase out
SSL Version2 ClientHello -- but had not started to do so yet
when TLSv1.2 was published (August 2008).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 20:40:09 +0100 (MET)

> <https://bugzilla.mozilla.org/show_bug.cgi?id=168800#c8>).

You entirely ignore that this was a real world test performed in 2006!

   A.2.  SSL v3 server refuses TLS 1.0 client (case 2)

       Date: April 5, 2006

       Server: Lotus-Domino/5.0.8

       Site: https://www.ecbanking.com.my/

We can not shut down the internet while people are individually
deploy patches at various times.

> with them for that reason.

I do not agree with these conclusions.

 - the sites have moved to different hostnames, and you can connect
   them perfectly fine with the hostname they use in their certs.
   Businesses rename all the time due to Marketing "requirements",
   and the admins are simply trying to be nice to their colleagues
   (e.g. keep Email-Addresses working) which might be the reason
   why the DNS-Entry redirects you.

 - there is no MITM at the TLS level when a server uses a certificate
   that does not match the hostname that the application used to
   establish the network connection.

   Server Endpoint identification is entirely an apps thing
   (e.g. HTTP over TLS [RFC2818])!!

   RFC 5246  1. Introduction  (last paragraph, top of page 5):

                        The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

   Btw. the server endpoint identification in HTTP over TLS is extremely
   weak, and if the HTTPS-Urls are served through HTTP-pages like
   with 98% of the use-cases,  the quality of that authentication is
   realllllly weak.

> obstacle to solutions to the renegotiation flaw that use extensions.

Those clients that send extensions by default seem to have added
app-level reconnect fallbacks for extension-less ClientHellos.

If there were no use-cases, these would not have been added.

So the alternatives currently are:

1)
    - submit a TLS fix with the highest possible interoperability
      (i.e. extension-less)

2)  - submit a TLS fix based on extensions
    - submit apps-fixes to disable fallbacks because of downgrade attacks
    realize that there are interop problems that can not be ignored
    - revert the apps-fixes, re-enable fallbacks
    - submit a different TLS fix without extensions to fix the downgrade attacks

Approach (2) involes a huge risk.  It may cost a lot of people
a lot of time and money and we might end up having to support
two different solutions for the same problem in parallel because
of the installed base created by the first fix shipment.

And then we will have security problems because shipments of the
first fix will not security interoperate with shipments of the
second fix, i.e. we would create yet another installed base,
just that it is much newer and therefore much harder to get
them to install the second fix -- especially considering that
we would then have fouled up the first one so badly.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 23 Nov 2009 20:06:43 +0000

> In the meantime, we can't ignore that IE6 running on no-SP Windows XP.

Your argument is self-defeating: if browsers are only upgraded slowly
(by some subset of users), then that is an extremely good reason not to
rely on browsers to be upgraded in order to prevent the attack. The only
possible way to do that is for patched servers to reject renegotiations
from unpatched browsers -- because such renegotiations cannot be
distinguished from an instance of the attack.

This will not break initial connections from unpatched browsers. It will
require that servers avoid relying on renegotiation, but they can easily
do so in a way that is compatible with IE6 or other unpatched browsers
(for the most common use case of renegotiation -- prompting for a client
cert for only some of the resources on a site -- it is sufficient to serve
those resources on a different port).

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 23 Nov 2009 12:28:15 -0800

On 2009-11-23 06:59 PST, Michael D'Errico wrote:

> I proposed a change to RI in another message that:
> 
>    - makes the extension empty in both directions on every handshake
>    - changes the Finished calc. in some way (there are various ways to
>      do it and I don't care which is chosen)

> What I don't like about the current RI proposal is that it uses extensions
> more than just as a signaling mechanism; you actually have to craft them
> in both directions and extract the data at the other end.  Plus as I pointed
> out, you need to actually check that the data received is correct.  

Checking that data is correct is a very large part of the value of security
software.

> If you agree that this is better/simpler than the current RI proposal, I'd
> appreciate it if you would send a note to the list enumerating these
> benefits.

I disagree with is emphatically.  I disagree with changing the definition of
the finished messages without changing the protocol version number.
The IMPORTANT thing that RI accomplishes is that it gets the needed
information included in the Finished message computations WITHOUT changing
the definition of the Finished message computations.  That is precisely
its strength!  That is precisely why I support it.

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 21:43:04 +0100 (MET)

Nelson B Bolyard wrote:
> 
>                             I disagree with changing the definition of

Great!  So you will not have a problem with my proposal either,
because mine does not change the finished message computation
either.

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

>From a cryptograpic standpoint, adding the verify_data into
the handshake message hashes without sending them over
the network is equivalent to adding them to the handshake
messages itself, sending them over the wire and having
to compare the values explicitly.

Just that directly hashing them is less work and get a
much better test coverage in regular interop testing,
while TLS extension RI requires formal code review or
penetration tests to achieve this.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 Nov 2009 22:44:17 +0100

> the finished messages without changing the protocol version number.

But changing the protocol version number is exactly what the alternative
proposal is doing.

> its strength!  That is precisely why I support it.

And this is also it's weakness as pointed out in previous mails, as it
allows bad implementations of the fix to appear good.

/Stefan

---

From: Ben Laurie <[email-masked]>
Date: Mon, 23 Nov 2009 14:11:56 -0800

> "be liberal in what you accept, be conservative in what you send out"

That has proved to be a less-than-great idea, particularly in
protocols where you care about security, which is to say, all of them.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Nov 2009 15:57:39 -0600

> Checking that data is correct is a very large part of the value of security

I prefer protocols where the checking is automatic.  To be more specific
in the context of this case: I prefer a solution where the two peers
must have added the same channel binding inputs to some operation such
that authentication will fail if they didn't.

That said I support the RI proposal for the simple reason that it is
ready to be deployed.

> the finished messages without changing the protocol version number.

I don't agree with you on this.  The protocol version extensibility
constraint that you are stating is completely arbitrary -- even if it
were written into RFC5246 it'd still be as arbitrary and could not
really bind the IETF in the future.

Arbitrary extensibility constraints can be, and are useful, but if they
lead to inferior solutions when new problems arise then they begin to
lose their utility.

> its strength!  That is precisely why I support it.

No, the important things about the RI proposal are that a) it does solve
the problem, b) it's ready to be deployed.  (b) alone would not be good
enough, obviously, but, less obviously, neither would (a).  Many
alternative proposals have (a) and do it better, but only this one has
(b).

Perfect is the enemy of the good.

IMO the RI proposal it is, even though I'd rather have a different
solution, and even if some of us agree for different reasons.

Nico
--

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 23 Nov 2009 14:58:02 -0800

> protocols where you care about security, which is to say, all of them.

Precisely.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Nov 2009 17:16:47 -0600

> protocols where you care about security, which is to say, all of them.

Sure, but consider this: a conservative design should fail safe.  The RI
proposal, as Michael D'Errico points out, allows for implementation
failures that fail unsafe.

Any alternative that has the two peers add the channel binding data for
the outer/old connection to the Finished message verify_data computation
without _sending_ the data as well will fail safe.

IMO there are better solutions, but the RI proposal is ready for
deployment at a moment's notice, and it is correct even if implementors
can make this one annoying mistake and not notice.  That is a huge plus
for the RI proposal.

Nico
--

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 23 Nov 2009 21:11:02 -0800

>> its strength!  That is precisely why I support it.

It does not change the finished message, or the computation of the handshake
hashes.  All remain 100% computable from the inputs to the
present handshake.

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

Your change makes the handshake hash (and hence the finished) no longer
computable purely from the input to the current handshake.

> Just that directly hashing them is less work 

It's a bigger code change, which is more to get wrong.
Where have I heard that argument used before?

---

From: Marsh Ray <[email-masked]>
Date: Tue, 24 Nov 2009 01:56:10 -0600

> protocols where you care about security, which is to say, all of them.

Another way to think about it: any time a receiver is being liberal in
what it accepts the protocol is depending on undefined behavior.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Nov 2009 11:08:00 +0200

> those resources on a different port).

A different port is hard, but the usual way is to have a "login_with_mutual_authentication.html" page, that is the only one where the renegotiation is performed. That page plants a session cookie in the browser, if such a cookie does not yet exist, and performs no other action. You also need to reject client-initiated renegotiation.

If you do that, the only way for the attacker to force a renegotiation, is to GET login_with_mutual_authentication.html, before the user logged in. This will plant a cookie in the browser of the legitimate client, but that cookie cannot be used for the attack, because the client's request has already been created without the cookie.

That's a way to support old browsers without being vulnerable. It only requires a mild change to SSL (no client-initiated reneg) and a mild hardening of the application.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 24 Nov 2009 10:36:21 -0600

> allows bad implementations of the fix to appear good.

I'm very sympathetic to the idea of "fail safe" design. However, it's
impossible for a spec to defend itself against an implementor determined
to do it badly!

So when evaluating the relative benefits of the proposals (under the
current circumstances) I would consider goof-resistance to be a nice
bonus, but not a primary factor.

Everyone can expect testing tools to be available for the well- and
ill-intentioned alike (e.g. Metasploit). That should help implementors
get it right.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 17:41:03 +0100 (MET)

> what it accepts the protocol is depending on undefined behavior.

There is a difference in what you accept (what your parser accepts)
and what part of that you actually use/believe/rely on.

That quote is about interoperability, and it against building
flawed assumptions into your code all over the place that will
blow up if the protocol is changed in a way that fits into
the spec, but makes flawed assumptions cause all sorts of problems.

A lot of "secure time servers" actually source their time from
a radio signal that is unprotected (simple and old protocols).

I don't know how much sanity checks they do.
A chain is only as strong as its weakest link.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 18:51:27 +0100 (MET)

> hashes.  All remain 100% computable from the inputs to the

That's exactly what I do, too.

TLS extension RI has the same additional input to the renegotiation
handshake as my proposal.  That is a requirement to make the
renegotiation secure.

> computable purely from the input to the current handshake.

Oh yes, it does!

The finished messages from the previous handshake are definitely
input to the current handshake.

In my proposal I just don't send the previous handshake messages
over the wire one more time, because there is absolutely no need
to (there were already exchanged in the previous handshake),
and it results in a failsafe design.

The finished message calculation includes the master secret,
and that includes public key operations, so deriving
the finished messages directly from what goes over the
wire has _never_ been possible with TLS.

> Where have I heard that argument used before?

It is pretty difficult to imagine a software implementation
where adding the verify_data directly to the handshake message
hash to result in more code.

It would have to be spaghetti code where the handshake message
hash is directly hardwired into the record layer behind decryption,
and only "reset_handshake_message_hash" and
"finalize_handshake_message_hash" implemented as seperately
callable functions, but not
"add_to_handshake_message_hash(handle, buffer,len)"

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 18:57:30 +0100 (MET)

> It's a bigger code change, which is more to get wrong.

Besides being less code, it is really hard to get this one wrong,
because regular interop tests with client and servers
will tell you exactly when you got it wrong.

Different to TLS extension RI, you do not Code Review or
Penetration testing to ensure that you got it correct,
it will do this all by itself.

If you're worried you get this part wrong,
you definitely should not contemplate TLS extension RI.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 24 Nov 2009 10:30:07 -0800

[ignoring the fact that a private message was forwarded to the list (and
  edited to boot)....]

No, you are missing the point.  The fact that RI gets the verify_data
into the next handshake hash does NOT improve security.  The added
security is only the result of manually checking that what was received
was correct.  This means that now we require 2 checks, that RI is correct
and that Finished is correct.  It would be easy for an implementor to
miss.  I know this because I almost missed it!  After getting the mechanics
of sending and receiving the extension correct, I was like, "Oh, sh*t!  I
forgot to check that it was correct!"  If I can mess this up, how can you
expect poor maintenance programmers to get it right?

The alternative I proposed here[*] requires only that the Finished message
continue to be checked as it is today.

I can see how you would like to not change the Finished calculation unless
the version is changed.  The problem with that is we have 4 versions to
patch and there can be only one successor version (e.g. TLS 1.3).

Mike

[*] http://www.ietf.org/mail-archive/web/tls/current/msg04600.html

---

From: David-Sarah Hopwood <[email-masked]>
Date: Wed, 25 Nov 2009 05:55:21 +0000

> protocols where you care about security, which is to say, all of them.

... and if anyone is not convinced yet that the "be liberal" part is
actually a *bad* idea, then read
<http://www.ioactive.com/pdfs/PKILayerCake.pdf>.

---

From: Chris Newman <[email-masked]>
Date: Thu, 26 Nov 2009 09:43:29 -0800

> I don't see how this would solve the problem.

This would solve the problem of SSLv3-only implementations that must be 
upgraded to address this issue being difficult to upgrade to full TLS with 
general extensions support.  That's a problem I believe may be worth 
solving for this particular security vulnerability.

It also addresses the very real problem that having two ways to negotiate 
the same thing is bad design and there have been proposals to negotiate via 
different protocol elements in SSLv3 than in TLS.

> is extensions-intolerant without being vulnerable to downgrade attacks?

The alleged extensions-intolerant servers were broken when they were first 
released and it is unfortunate their failure to comply with standards was 
not identified and fixed sooner.  Since they must be upgraded to either be 
made secure or identified as secure, why not fix the standards-compliance 
bug (failure to tolerate extensions) at the same time?  Seems a lot cleaner 
and safer than kludging crap into critical fields in the ServerHello.

So this is a problem that I do not consider worth solving -- indeed I 
prefer solutions that break implementations that already demonstrated an 
inability to follow published standards.  As a pragmatist, I'd consider an 
exception if a particular implementation was widely deployed and difficult 
to upgrade, but we'd need to see a list of these non-compliant servers to 
make that evaluation.  If nobody is motivated enough to produce that list, 
I assume none of them are problematic.

		- Chris

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Nov 2009 19:21:10 +0100 (MET)

> different protocol elements in SSLv3 than in TLS.

This was one of my biggest complaints all the time.  I want only 
one single solution for SSLv3->TLSv1.2, because it is exactly the
same problem affecting the entire installed base.

> not identified and fixed sooner.

There are still SSLv3 servers around, and as I've recently learned,
the original Netscape SSLv3 spec did not provide for TLS extensions,
Netscape offered the extensions-intolerant SSLv3 spec much more
prominently than the SSLv3 document that was created in the TLS WG,
and unfortunately the TLS WG never cared to publish the
forward-compatible extensions-tolerant SSLv3-spec as an informational RFC.

If anyone is to blame that the situation is as bad as it is
concerning TLS-extensions interop, then it is certainly the
IETF TLS WG that didn't care about it for _MANY_ years.

RFC-5246 Appendix E clearly shows the attitude:
there exist workarounds to address the interop problem,
that's good enough. we don't care.

>                                  Since they must be upgraded to either be 

Many of those that we want to upgrade might not actually be vulnerable
(at least not in such a serious fashion as some webservers).

So if you want them to consider patching their software,
offending them or making the patch unnecessarily complex is
definitely not going to help improve the situation.

> inability to follow published standards.

If you do that for new protocol versions, that's fine.  The market
will decide whether it needs a fubar-ed standard or not.

Implementing the standars correctly didn't save anyone from
the need to patch now.  But those who didn't follow the
recommendation to support renegotiation do not have as much
of a problem as the compliant ones right now.

But when you're trying to fix something many years into the past,
then _NOT_ breaking the installed base is imperative.

The TLS WG produced 2 TLS protocol revisions after TLSv1.0
and a lot of surrounding documents -- instead of reviewing
the security properties of TLSv1.0.  That this bug has gone
so long without being noticed and is now part of a huge
amount of installed base, some of which is long out of maintenance
but still in use.  It is definitely not the consumers of
the SSLv3/TLS technology which are to blame here.

-Martin

---

From: Chris Newman <[email-masked]>
Date: Thu, 26 Nov 2009 11:18:07 -0800

Actually, the quote is sensible but has been taken out of context and 
misused widely within the IETF.

The "be liberal in what you accept" means accept _all_ valid standards 
compliant protocol (e.g. things like mandatory-to-ignore extensibility 
fields).  It never meant that implementations should accept incompliant 
protocol.

The "be conservative in what you send out" means to use the minimal subset 
of the permissible standard syntax to accomplish your goal.  For example, 
the email/http header "Content-Type: text(hi there/hello;)/ plain" is 
permissible by the standards and semantically equivalent to "Content-Type: 
text/plain".  But a conservative implementation will never generate the 
former.

(As a matter of good protocol design, it's better if the conservative and 
liberal protocol syntax is as close as possible).

So the RI extension is fully compliant with the golden rule, while the 
alleged extension intolerant server implementations are clear violators of 
the rule.

In my experience, protocols where early implementations reject incompliant 
protocol aggressively end up with much better real-world interoperability 
and are much easier to get working by just reading the spec.  Protocols 
where widely deployed early implementations tolerate incompliant 
implementations end up with systemic interoperability problems that never 
go away (e.g. SMTP "just send 8-bit with unlabelled charset"), and require 
a lot of real-world experience beyond the specification in order to produce 
a production-quality implementation.

As a pragmatist, I recognize it is sometimes necessary to accommodate 
widely deployed broken software, but such accommodation requires supporting 
data, justification and needs to be as narrowly tailored as possible or the 
real world drifts away from the standard and overall systemic 
interoperability gets worse even if that one point-to-point 
interoperability case is better.

		- Chris

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 26 Nov 2009 19:55:04 -0800

> and safer than kludging crap into critical fields in the ServerHello.

I categorically agree with the above statements.

Who is to say that this is the last serious vulnerability that will be found
in SSL 3.[0123]?   When the next one is found, will we again be urged
to steal more bits in existing SSL 3.0 message fields?

Marsh Ray made the excellent point that SSL 3.0 was (in some sense) doomed
from the start by the lack of any extensibility feature that allowed flaws
like this to be addressed without changing the base protocol.  EKR's RI
proposal clearly demonstrates the capability of TLS's extension facility
to be used to cleanly and simply fix problems like this WITHOUT needing to
make ANY changes to the base protocol at all (not needing to incorporate
phantom messages into the handshake hashes).

As keepers of the public's trust to specify standards for transport layer
security, it behooves us to evolve the protocol in ways that look forward
to the possibility of another vulnerability being found in the base
protocol, and not be forced to rely on yet another hack to all existing
versions of the base protocol, and yet another encroachment on the version
number space, to fix it.

> I assume none of them are problematic.

I agree.  Let's see some evidence, beyond the mere fact that the browser
developers have not found it urgent to remove their SSL fall-back code
11 years after they put it in, that the Internet and its users really
depend on those non-standard servers before we agree to forever codify
the nonstandard behavior of those servers in a new RFC.