Subject: [TLS] RI, TLS Extension tolerance and version tolerance in servers

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 12 Dec 2009 21:01:17 +0100

Hello all,

With the introduction of the RI extension it seems to me that the
implication is that all patched servers must, as a consquence, become TLS
Extension tolerant, also the SSL v3-only servers.

However, my feeling is that section 5 in the -01 draft is not completely
clear on this; although the implication is crystal clear for
renegotiation, it is IMO not clear enough for the initial handshake on a
connection. I think section 5 needs to add that clients supporting RI MUST
send the RI extension when it knows it is talking to a server supporting
RI. The only excpetion would if the client is restricted to the
no-renegotiation case in section 4, in which case it can send the MCSV to
servers that are known to support RI. While it is implied by the first
paragraph in sec. 5, it may also make sense to state that the client MUST
use the MCSV in fallback mode, but that it does not need to send it when
it is sending RI to a server known to support RI, it might actually not be
necessary to send it when using the RI extension at all, since a patched
server MUST support the extension.

I also think that a client supporting RI which, due to fallback
negotiation procedures, sent a MCSV-only handshake MUST, upon discovering
that the server supports RI, terminate the connection (with a warning
close notify, since it is not a real error), and re-establish the
connection with a Client Hello that uses the RI extension. The reason for
this will become clear below.

If this is implemented, this means that all patched servers will be TLS
Extension tolerant, even if the only extension they understand is the RI
Extension.

Given this fact, I think it would not be much of a stretch, or
compliaction, since it is already part of the specification for all SSL
and TLS versions, to require RI supporting servers to *properly* implement
RFC 5246 section 7.4.1.3's requirement for the Server Hello:

      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.

and section 7.4.7.1  (RSA pre-master secret; sidenote: is it possible to
implement something similar for non-RSA keyexchange?)

         client_version
            The latest (newest) version supported by the client.  This is
            used to detect version rollback attacks.

These requirements are in all versions of TLS and in SSL v3.0 (whichever
draft is considered the "real" specification), and requiring correct
implementation should not be controverisal (crossing fingers), and I think
the RI specification should reiterate this.

With such a re-iteration a separate requirement could be stated for
clients: When sending the RI Extension they MUST identify the highest
SSL/TLS protocol version they support, and it is a fatal error (no
fallback permitted) if the server refuses to negotiate such a Hello, since
such a refusal must be considered an attempt to perform a version rollback
attack.

Adding this requirement would close another protocol vulnerability,
version rollback attacks. This type of attack is currently theorethical,
since there are AFAIK no known weaknesses in SSL v3 or TLS that can
realistically be leveraged if the client and server is forced to use such
older protocol versions (there is the CBC attack, though), but adding this
requirement will, if implemented, close the hole. It is currently trivial
to force the Browser clients to perform a version rollback, due to the
interoperability concerns I have mentioned before.

To sum it up, my proposal is as follows:

    - All servers implementing the RI-spec MUST support the RI extension in
Client Hello's, and therefore be extension tolerant
    - All servers supporting RI MUST implement the correct version
negotiation method, that is, become version tolerant.
    - All clients supporting RI MUST send the RI extension to servers they
know support RI (non-renegotiating clients excempted)
    - All clients supporting RI MUST specify their highest supported TLS
version in the Client Hello when they are sending the RI extension.
Failure to complete negotiation must be considered a fatal error and an
indication of a version rollback attack on the connection; the client MUST
NOT try to negotiate the connection using an older protcol version.
    - All clients supporting the RI Extension, but using the MCSV-only
fallback Client Hello to a server that it does not know whether or not
supports RI MUST shut down the connection if the server indicates RI
support and re-establish the connection with RI and highest supported
version number to ward off a potential version rollback attack. Failure to
complete negotiate in this situation is a fatal error and must not result
in a fallback.

If implemented, this set of proposals will make all patched servers
version and TLS extension tolerant, secure them against a possible attack
method if they were not already secure against it, and remove the need for
clients to support a fallback to older protocol versions once they change
to a strict mode with respect to servers that have not been secured against
the renegotiation attack (and as I've mentioned earlier, the effort to
secure the currently existing protocol versions is wasted if such a policy
change is not implemented within a reasonably short time after the RFC is
published; if it isn't, this fix can just as well be implemented in TLS
1.3 instead).

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

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Dec 2009 03:11:02 +0100 (MET)

Yngve N. Pettersen wrote:
> connection with a Client Hello that uses the RI extension.

I'm sorry, but I think that is a particularly bad idea, and completely
unnecessary.  In the IETF we are supposed to define and/or extend
protocols in a fashion that promotes interoperability.

The purpose of the MCSV is _NOT_ to prevent secure renegotiation in the
fashion you describe.  MCSV is the Client->Server signal that should
be both usable and non-disruptive to all existing SSLv3 and TLS
usage scenarios.

A server that receives a ClientHello with MCSV must treat
this exactly as if it had received an empty TLS extension RI.

The only thing that a server needs to know for the initial handshake
is that the client has been updated.  It is definitely not
necessary that the server asks the client to put a bow on it
and retry.  

If that handshake is an initial handshake for the server, then the
server must respond with a ServerHello containing an empty
TLS extension RI.

If the handshake is a renegotiation for the server, then the server
must abort the handshake with a fatal handshake alert.

Old servers that do _not_ need renegotiation do not need TLS extensions
either.  They will look purely for MCSV and return 7 extra bytes
on ServerHello following compression method -- aka "RI-minimal".

> Extension tolerant, even if the only extension they understand is the RI

There is a misunderstanding about the term "Extension tolerant".
That is supposed to characterize the ClientHello forward compatibility
in the 18-Nov-1996 SSLv3 document, in TLSv1.0 (rfc-2246) and
TLSv1.1 (rfc-4346).  It means that the server receiving data after
compression_methods in ClientHello will tolerate the presence of
this data, but otherwise _completely_ ignore it.

The client MUST send MCSV on _every_ ClientHello, so that the
Client->Server signaling completely condition-free, which will
make it trivial to implement and robust.  This easy rule
completely obviates any talking about special cases or
attack scenario.  

Every TLS handshake requires an initial ClientHello, and if that
ClientHello always carries the Client->Server signal (which is
easy to accomplish for the MCSV and non-disruptive to existing
usage scenarios, then it will be completely impossible to
lure an updated client into an old renegotiation with an updated
server, no matter how willing client and server are to
perform backwards interoperable renegotiations with old peers.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 14 Dec 2009 03:33:04 +0000

> necessary that the server asks the client to put a bow on it

You're missing the purpose of Yngve's suggestion, which is to prevent
version rollback attacks against clients that currently do fallbacks.

Suppose that the next weakness found in SSL/TLS is something that was
fixed in TLS 1.0, 1.1 or 1.2. Then preventing rollback attacks will be
critical, and we'll rue not having adopted Yngve's idea.

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

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 14 Dec 2009 12:16:58 +0100

> protocols in a fashion that promotes interoperability.

Please note my pre-requisite for this suggestion: That the server MUST be  
Extension tolerant (preferably extension understanding, but that is beside  
the point in this case), and that this suggestion is mostly intended to be  
used in combination with the second requirement of my proposal: Version  
tolerance. As I said, "The reason for this will become clear below."

A client that does a MCSV-only is almost certainly indicating a version  
less than its highest supported version, and is either doing that because  
it has been forced to fall back to an extensionless Hello (by intolerance,  
which rules out an RI capable server, based on my requirements, or by an  
attacker), or because the client is climbing the version ladder (like  
Opera), in which case it should try a higher version immediately, anyway.

In combination with my suggestion of directly stating requirements on RI  
capabable clients and servers about which SSL/TLS version is to be sent in  
Client Hellos and serverside version tolerance, the MCSV-only handshake  
can be used to detect a version rollback attack and counter it by  
immediately starting to use a Client hello that states highest version.

> this data, but otherwise _completely_ ignore it.

Maybe I should have said "understands TLS Extensions", but that is only a  
requirement in my proposal if MCSV is optional in an RI-hello, and my  
understanding of the *current* text in -01 is that the MCSV *is* optional  
when the RI is sent. My suggestion is to clearly enumerate the cases where  
it is required, and when a client MAY send it.

However, I think that there is going to be very few (if any) cases where a  
server vendor knows in advance that the server is never going to do  
renegotiation and is never going to accept it. In those cases I also  
suspect that the vendor is also in control of the client software, and in  
such special cases a vendor can probably do whatever they want.

In just about all other cases we will be talking about general purpose  
servers where it is at least conceivable that they will have to complete a  
renegotiation in some deployments, and in those cases the server MUST  
understand the RI extension, also in the initial handshake.

I therefore think it is unlikely that a general purpose client will  
encounter a server that does not understand the RI extension, and IMO we  
might just as well make it a requirement that all servers MUST understand  
the extension. But I can live with the possibility that the MCSV have to  
be sent in all initial handshakes, as long as all servers MUST at least be  
TLS extension tolerant.

The main point of my entire suggestion is that since ALL servers and  
clients have to be patched anyway, that the RI proposal already makes (at  
least) TLS tolerance a requirement, and that many servers are implemented  
in a fashion that forces all general clients to behave in an unsecure  
fashion (automatic version rollback) it would also IMO be a very good idea  
to close that security hole at the same time as we close the current hole,  
and make it very clear that the version negotiation problem will no longer  
be tolerated by RI capable clients.

This is an opportunity to close *two* security holes at the same time, and  
I think we should take it.

If we don't take this opportunity, we may well have to repeat the "patch  
all servers" routine again in, at most, a few years. I think that is an  
expensive way to save a few hours of checking that a few lines of code are  
actually doing what they should have been doing the past 15 years, and if  
necessary fix them.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Dec 2009 16:40:03 +0100 (MET)

> immediately starting to use a Client hello that states highest version.

This sound somewhat inconclusive to me.  If it is possible to force
a client to perform a re-connect fallback, then we can not provide any
protection against this at the TLS protocol level.  The purpose of MCSV
is to provide protection from insecure renegotiation between updated
TLS peers even for fallback-scenarios, so there is nothing that
needs to be done for the secure TLS renegotiation part.

Since we are, in fact, suggesting SSLv3 servers to add the renegotiation
protection patch as well, it would be a flawed assumption that a
server would select newer protocol features if the client had simply
sent a more feature-rich ClientHello.  In probabilistic terms, it
might, but since you are talking about a client that will use a
feature-rich ClientHello as default and what you described would only
apply to the fallback scenario, then most of the time this will be
simply an old server.

The majority of programmatic clients likely do not have any app-level
retry logic and neither do they keep lists of servers an the TLS features
these support in order to optimize their app-level retry logic.
Usually, those clients just want conservative protocol defaults
for their ClientHello so that they have a high likelyhood to
obtain interoperability with most of the installed base.

> be sent in all initial handshakes, as long as all servers MUST at least be  

To get rid of complexity, the empty TLS extension RI for ClientHello
should be completely removed from the specification (i.e. MUST be ignored
by servers if present).

Implementation-wise it will be even simpler and more robust,
if MCSV is sent on every renegotiation handshake as well
(i.e. unconditionally included in all ClientHellos), even when
there is an accompanying TLS extension RI with Client.Finished.verify_data.

This will facilitate code that allows backwards interoperable
renegotiation (server-side).  If either the current session is
already marked for secure renegotiation or the incoming ClientHello
carries the MCSV, then the strict rules for secure renegotiation
processing apply, no matter how willing the server is to perform
old renegotiation based on its configuration (admin requirement).

> be tolerated by RI capable clients.

Some server will not be patched, and for a non-negligable time we will
have a mix of old and updated peers out there, and every day some more of
the old will become updated.

> I think we should take it.

*I* would not refer to the fallback re-try logic in your Browser as
a security hole.  It definitely does not need to be one, and it's
completely up to your implementation to ensure that.

Your idea is an expensive mitigation strategy at best
(security by obscurity).  If you really wanted to improve that, then
it might be an idea to signal back to the client the highest supported
SSL/TLS protocol version of the server along with the currently
empty TLS extension RI -- and make the initial TLS handshake complete(!)
(only when the handshake is completed successfully, the information
exchanged during the TLS handshake is authenticated.

Most clients do not intend to renegotiate the session themselves,
and the majority of programmatic clients is unlikely to cache/memorize
such data returned by the server for future TLS sessions.

> all servers" routine again in, at most, a few years.

I don't understand what you are refering to.

The issue that maintenance folks should check, when they touch any old code,
is what I described in Appendix A.1 of my I-D.

-Martin

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 14 Dec 2009 17:59:54 +0100

> needs to be done for the secure TLS renegotiation part.

I am talking about a client, as all current Browser clients, that have to  
allow the use of non-extension handshakes because of interoperability  
reasons.

In that *particular* situation, when it does not know that it is about to  
talk to an RI patched server. Upon discovering that it is indeed RI  
patched, based on my suggestions for requireiement the client knows two  
additional things: 1) It can use the RI extension with this server, and 2)  
it have to make sure that it was not forced to use an older SSL/TLS  
version than it supports. Therefore it should tear down the connection and  
re-establish it, in Opera's case signalling support for TLS 1.2 and using  
the RI extension, and (again assuming my proposal is accepted) the server  
will accept the hello, respond with a RI extension and its highest  
supported version if it is lower than Opera's, and Opera's if the server  
supports a newer version. If the handshake fails in this situation  
somebody is trying to perform a version rollback attack against the client.

> apply to the fallback scenario, then most of the time this will be

The SSL v3 server does not have to select newer protocol features, it just  
have to *tolerate* that the client uses them.

If the server supports renegotiation it will have to implement support for  
the extension, and it have to be flexible enough to handle whatever  
syntactically correct extension list the client sends.

If the server does not support renegotiation then it might not support the  
extension, but my proposal is that it MUST be TLS Extension *tolerant*. I  
am however suggestion, optionally, that supporting the extension should be  
a MUST in patched servers.

> obtain interoperability with most of the installed base.

I am not talking applevel, I am saying that the SSL/TLS implementation  
must restart the connection. The case where that may cause problems, is  
for upgradeable protocols features like SMTP STARTTLS, and I assume that  
all those clients either already have a fallback mechanism that requires  
restart and have an application layer that can handle that, or they signal  
their highest version and uses extension (if they support it) all the  
time, and expect the server to tolerate it.

If it is desirable to avoid restarts, the simple way to handle that is to  
signal highest version and the extension, and require the server to handle  
it.

> should be completely removed from the specification (i.e. MUST be ignored

I disagree. The empty RI should be the default, and the MCSV only used  
when a *lenient* client connects to an *unknown* server, optionally using  
a fallback to a configuration that does not support extensions.

> if MCSV is sent on every renegotiation handshake as well

I am working within the framework of EKR's document.

> Client.Finished.verify_data.

My suggestion does not really touch on that scenario, but my  
recommendation is that the MCSV in only sent in the initial handshake, but  
as long as clients are lenient they may send it in any handshake. Strict  
clients should only use handshakes with the extension, and identifying the  
highest supported version. MVCS should only be used in this case if  
support for the extension is optional in servers that does not support  
renegotiation, but I think that is going to be such a limited amount of  
instances that it is better to require extension support in all servers.

> the old will become updated.

My position is that the time for changeover before clients turn strict  
should be no more than 12 months, preferably less.

If we allow a more extendend period for upgrades we can just as well drop  
the current discussion and start working on fixing it in TLS 1.3 instead,  
we won't possibly be able to turn strict before that protocol version is  
widely deployed in year 2020 or 2025.

> completely up to your implementation to ensure that.

It is *impossible* for such fallback code to determine if the server is  
broken or there is an attack going. To interoperate we have had to open a  
security hole, and it is time and more than time to close it permanently.

As it sounds like you may have a way to determine if a connection  
shutdown, no response withing a timout, or a finished message that fails  
is due to a server implementation "mistake", and is not an attack intended  
to force me to use an older version of the protocol, perhaps you can  
provide more details?

> Your idea is an expensive mitigation strategy at best

Expensive? Making sure an if-then-else clause and a variable check is  
correct should not be expensive, nor should fixing it be expensive either.  
The servers have to be fixed anyway.

> exchanged during the TLS handshake is authenticated.

There is already a way for that signal: The client signal its highest  
version, the server selects the lowest of its version and the client's  
stated version, and in RSA also double check this with the version number  
in the RSA Premaster Secret.

There is no need for a more complex signal; we just have to fix the broken  
servers that insist that clients can't use a higher protocol version than  
the one they use.

> I don't understand what you are refering to.

What I am saying is that it is conceivable that we could have a break in,  
for example, SSL v3 that makes a live attack on the protocol feasible, but  
only if it can trick the client and server to negotiate a SSL v3.0  
connection, and today that is *trivial*; all major clients do it  
*automatically*! Once that news reach the community there will be a mad  
scramble to disable SSLv3 in servers and clients, and to disable the  
fallback. Let's not wait for that to happen, let's avoid that scramble,  
let's remove the very reason why we need a fallback, at least in strict  
clients and against known RI-patched servers, and let's do it *now*.

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Dec 2009 20:11:48 +0100 (MET)

> somebody is trying to perform a version rollback attack against the client.

That is _not_ a version rollback attack (on the TLS protocol version),
but instead a downgrade attack on your fallback logic.  It is unrelated
to the TLS renegotiation vulnerability.

> must restart the connection.

Going through a handshake failure would be a fairly broken solution
an can not possibly work at the TLS protocol level.

What you could use is either the MS SGC logic (which internally
restarts the handshake mid-way), or successfully complete the
handshake and renegotiate immediately after with better features.

Any form of handshake failure, reconnect and new handshake will
require apps-level support for this.  Quite a number of TLS implementations
do not include transport, and even those that include transport can
usually not perform a re-connect all by themselves.  (How many
TLS implementations perform things like a HTTP CONNECT proxy traversal
all by themselves, instead of getting an established network connection
handle where they should start a TLS handshake?

> 
>                               The case where that may cause problems, is  

I assume that few, if any, have a fallback retry logic.

They usually may have a possibility to select a protocol version upfront
(SSLv2, SSLv3, TLSv1), and depending on their age (or more precisely
the age of their TLS implementation), might not be using TLS
extensions so far, even when TLSv1 is selected.

The "canonical" clients would be "curl" and WinHTTP.  Which one of
these currently has a fallback retry logic?

> signal highest version and the extension, and require the server to handle  

You can implement whatever fancy fallback logic you like in your
TLS clients.  Just make sure you do not end up in a deadly embace.
(that might be particularly bad for mobile customers of the Opera
browser which pay-per-volume).

IMHO, Nothing of this belongs into a secure TLS renegotiation solution.

> a fallback to a configuration that does not support extensions.

That would be adding unnecessary complexity without value.

Either you do not need MCSV, then you should get rid of that,
or you need MCSV, then you should get rid of empty TLS extension RI
_in_the_ClientHello_.  Having both is a completely unnecessary
complexity, requires extra code, extra testing, will lead to extra
bugs and amounts to pure waste.

> I am working within the framework of EKR's document.

Me 2.

> as long as clients are lenient they may send it in any handshake.

If the solution needs to distinguish special cases or scenarios,
then it is way to complex.

Every conditional in your description creates at least one additional
conditional in the code (often more), which increases code size
and complexity, requires additional test cases and make the solution worse.

> should be no more than 12 months, preferably less.

Btw. I still haven't understood what the "lenient client" and
"lenient servers" are that some people have been refering to.

Possible backwards interop scenarios are the following:

1. updated client allowing initial handshake with old server
2. updated client allowing renegotiation handshake with old server
3. updated server allowing initial handshake with old client
4. updated server allowing renegotiation handshake with old client

The one we _need_ to get rid of is (4), the one we hope to get rid
of after transistion is (2).  (1) and (3) will likely need to be around
_much_ longer than 12 months.

> security hole, and it is time and more than time to close it permanently.

If you think it is a security hole, then you are free to disable it
_in_your_implementation_.

Personally, I do not think there currently is a known serious
security problem with an extension-less SSLv3 ClientHello.

> The servers have to be fixed anyway.

It is also expensive in terms of testing an extra code path,
in particular if you have a dozen or more seperate codelines unter
maintenance, but I was rather refering to network overhead
--a full new connection setup overhead, which may involve TCP
3-way handshake and whatever apps-protocol overhead is prefixed
to the TLS communication plus the network data, which may result
in a significant extra latency on connection setup (as seen 
by the app).

> in the RSA Premaster Secret.

No, there is not.  You mentioned it yourself, that in your fallback you
will send a low protocol version number in ClientHello.client_version
(maybe even { 0x03, 0x00 }, which is why you came up with the fancy
ideas to close the connection and retry -- simply because you do
_not_ know the highest protocol version that the server actually
supports.

The poor interoperability of newer TLS protocol versions with the
installed base goofs the entire "version rollback protection" design
in the original protocol.  The client has simply no idea whether
the server is doing a good choice when selecting a common
protocol version or a common cipher suite (some servers actually
seem to be doing a poor job at selecting ciphers suites).

> fallback.

I'm sorry, I don't see that problem.  The Browsers I have, even those
as old as MSIE 6 on Windows XP let me disable SSLv3 support if I want to.
Maybe there is a problem in your _implementation_ ?

Btw. I observed that MSIE 7+ on Vista will not allow AES ciphersuites
(rfc-3268) to be negotiated for SSLv3.  I know that it is not
specified to apply to SSLv3, but that does not mean that it could not
be used there.  Firefox seems to tolerate AES ciphersuites in combination
with protocol version { 0x03, 0x00 }.

-Martin

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 14 Dec 2009 21:15:38 +0100

> to the TLS renegotiation vulnerability.

IMO there is no real difference, since the fallback logic was added to  
handle broken server implementations.

> handshake and renegotiate immediately after with better features.

Not a good idea since it requires that the server knows about it. MS was  
in charge of both sides for SGC.

> Any form of handshake failure, reconnect and new handshake ill

The clients that have fallback is already able to handle that.

As I mentioned futher down, clients that doesn't just have to specify the  
highest version they support.

> extensions so far, even when TLSv1 is selected.

Well, I am talking about clients implementations supporting TLS 1.1 or TLS  
1.2, with Extensions used for those protocol modes.

> these currently has a fallback retry logic?

No idea, but curl probably sends the highest supported version, and fails  
if the server refuses to talk. The Windows HTTP stack probably perform a  
fallback if necessary, handled by the Windows SSL stack.

> browser which pay-per-volume).

I want to get rid of the fallback, or even the upgrade (fallup?) mentioned  
above, and in the case of the upgrade it is a temporary measure until the  
client enters strict mode.

>> >> be sent in all initial handshakes, as long as all servers MUST at  
>> least
>> >> be
>> >> TLS extension tolerant.
>> >

In a lenient mode MCSV seems necessary, but not after strict mode has been  
entered, assuming TLS Extension tolerance is a requirement.

> "lenient servers" are that some people have been refering to.

"Lenient client" means that it is willing to talk to an unpatched server,  
"strict client" is one that throws a fatal error when not receiving the RI  
extension from the server.

My position is that lenient clients should only be so for a specified  
number of months, after which they become strict.

> _in_your_implementation_.

As I've pointed out, repeatedly, the fallback is there because it is  
necessary in order to connect to major sites using broken server, such as  
the bank I mentioned a couple of weeks ago.

> security problem with an extension-less SSLv3 ClientHello.

No, there isn't. Right now, that is, as far as we know. What about in a  
year or three? (Keep in mind that it took a while for the renego issue, or  
the 2008 DNS issue to become publicly known)

> It is also expensive in terms of testing an extra code path,

Only if the server was non-compliant *already*, if it is compliant, no  
need to do anything.

If there is a problem, better fix it now when they have to ship an update  
anyway, or they will have to rush out a fix when the clients get tired of  
waiting for the last few servers and just disable the fallback. That is  
likely to be much more expensive.

> _not_ know the highest protocol version that the server actually

Only because we have all had to add a fallback in order to handle bad  
servers, which implicitly broke that protection. If clients start using  
the correct version (and ignore the howls from users and web site owners)  
that system will be back in function again automatically. No need to do  
anything else, except requiring servers to play along, which is why I  
would like those requirements about TLS Extension tolerance and version  
tolerance in the RI specification; and much of the version tolerance part  
is really just a reminder about what all the SSL and TLS specifications  
already say.

> Maybe there is a problem in your _implementation_ ?

No, there is no such problem in my implementation, in fact, with respect  
to SSL v3 I can turn it off in all deployed Opera 10.00+ installations  
within 7 (seven) days. The same thing apply to MD5 and SHA-1 in  
certificates, and will soon apply to the unpatched renego servers and the  
TLS fallback, and as soon as I get around to checking the state-engine (or  
remove the ladder climber aka the fallback), TLS 1.0 and TLS 1.1.

The real problem is deploying such manual workarounds. Just how many users  
do you think disable Javascript or plugins because of the latest issue in  
their browser? No need to answer. Very few.

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 14 Dec 2009 13:18:19 -0800

> actually doing what they should have been doing the past 15 years, and if  

I fully agree with all these points.  TLS was designed to detect and defeat
version roll-back attacks.  Clients that do "TLS intolerant fall-back" due
to servers that do not properly negotiate version numbers and do not
tolerate unknown extensions are clients that are completely vulnerable to
version roll-back attacks.

I fully endorse your proposal, but I only represent a TLS library used by a
browser, not a browser.  I hope that other browsers (in addition to Opera)
will also endorse your proposal very soon.

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Dec 2009 00:28:49 +0100 (MET)

> 1.2, with Extensions used for those protocol modes.

I just checked the implementations that I have around here.

* MSIE7 on Windows 2008:  offer TLS extensions, but Internet Options
  says about available protocols:  SSLv2, SSLv3, TLSv1.0

* MSIE7 on WinXPpro64bit: no TLS extension, Internet Options
  shows available protocols: SSLv2, SSLv3, TLSv1.0

* Firefox 3.5.5: offers TLS extensions. Protocol versions shown
  in Options/Advanced-Section/Encryption Tab: SSLv3, TLSv1.0

* OpenSSL-0.9.8l: offers TLS extensions, available protocol
  versions appear to be SSLv2, SSLv3, TLSv1.0

TLSv1.1 or even TLSv1.2 seems to be not exactly common these days.

There probably still are a few interop problems around TLSv1.0 {0x03,0x01}
but I would not be surprised about interop problems for TLSv1.1 and above.
What isn't tested, can not be blindly assumed to work.  Waving with
a TLSv1.1 or TLSv1.2 spec is not going to impress any of the deployed
code, and only marginally impress vendors, I assume.

> number of months, after which they become strict.

I'm confused why you removed the list that I showed here.  If you
really want to discontinue talking to all SSL/TLS peers that have not
been updated, then this is likely to have that Opera version drop out
of the client access statistic of a number of websites.

Such an action would be significantly more disruptive than suddenly
sending TLS extensions on every ClientHello.

Personally I think it is a bad idea to alienate your own users
with a new version of your software -- or a patch to that effect.
Making your users regret the have the software on auto-update
is going to hurt everyone. 

> the 2008 DNS issue to become publicly known)

The TLS renegotiation issue went unnoticed for so long because nobody
cared to look for it.  To me it looks a little weird that so many
implementors have missed it entirely.

I don't know what you mean by 2008 DNS issue.  Is it about the
embedded NUL characters in distinguished names?  Or the OID integer
overflows in attribute OIDs of distinguished names?  That is also
a mystery to me how so many implementers got this wrong.
To me, this suggests that a spec as complex as TLS extension RI
and as underspecified as draft-ietf-tls-renegotiation-01 will
turn a single common problem into a whole set of new interop
problems.

> >>               Once that news reach the community there will be a mad

A TLS client in form of a web browser that offers active content
and Javascript worries about the security of SSLv3 vs TLSv1.x?

In this constallation, _my_ empathy level drops to plain zero.

There are bugs found in Javascript and other active content on a
monthly basis.  It can be switched off by users.  It won't.  And
I haven't heard you proposing to disable active content through
SmartUpdate (or whatever you call it), although that would probably
improve the security on the internet _MUCH_ more than deprecating
extension-less SSLv3.

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 15 Dec 2009 01:57:40 +0100

> TLSv1.1 or even TLSv1.2 seems to be not exactly common these days.

  * Opera 10 with TLS 1.2 (and TLS 1.1 since 8.0, enabled since 9.0)

  * MSIE 8 and IIS on Windows 7, but disabled by default.

> code, and only marginally impress vendors, I assume.

I would not wave with the TLS 1.2 spec. I would wave with the last SSL v3  
draft and the 10 year old TLS 1.0 spec or whatever is relavnt for that  
particular server. Both of those says exactly the same as TLS 1.1 and TLS  
1.2 about version negotiation and extensions, and how they are to be  
handled.

I'd be waving the TLS 1.2 spec at another TLS 1.2 implementor if there was  
an interoperability problem between our implementation, or he would be  
waving it at me; but for an server supporting an older version of the  
protocol encountering a client supporting a newer version the rules are  
crystal clear, and have been so for about 13-15 years. It is about time we  
start enforcing those rules.

> is going to hurt everyone.

What makes you think we would go solo on such an action? What I have  
stated is my opinion about what should be done and my preferred timeframe,  
not what has been decided, which is still very much up in the air. I have  
also stated what preparations I am going to make for the time when such an  
action can be carried through, whether it is 6 months or 10 years from now.

Such an operation would at least have to be coordinated with all the major  
browser vendors and a date agreed upon.

And yous seem to be making the (IMO) mistaken assumption that web site  
owners will not move to update their servers if/when it becomes an issue.  
For that matter they are probably already waiting impatiently for renego  
fixed servers so that they can tell their users that their site is secure.  
For that matter, I wonder how long before the web sites become strict  
about the renego issue?

> implementors have missed it entirely.

My point was about time from discovery to publication.

> I don't know what you mean by 2008 DNS issue.  Is it about the

As in the DNS issue discovered by Kaminsky and revealed summer 2008 that  
required all DNS servers to be updated. (much like the current  
renegotiation issue)

> a mystery to me how so many implementers got this wrong.

Rethorial question mayb, but:

Why did the Y2K problem develop?

Too many assumtions, maybe? Possibly including assumptions about how it  
could be fixed properly later, before it became an issue?

Some string representations use a length field (like ASN.1), other  
NUL-termination. When the first was converted to the second, nobody  
considered the possibility of a NUL in the middle of the string, quite  
possibly because it was not possible in the format they normally used.

In the integer case you have a format that can represent integers of  
virtually any size; known examples all fit into 32 or (later) 64 bit,  
which made them easy to handle... Take it from there.

> turn a single common problem into a whole set of new interop

A reference implementation would help, which was one of my suggestions in  
the TLS interoperability draft.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 14 Dec 2009 17:24:13 -0800

> A reference implementation would help, which was one of my suggestions 
> in the TLS interoperability draft.

My server has been updated to speak RI (0xFF01) and MCSV (current
value is 0xBFFF):

      https://www.mikestoolbox.net

And I added a feature where if you ask for a particular page it will
turn around and act as a client, connect to your IP address on port
443, request "/", and then attempt to renegotiate using RI.  Send me
a private email for the link.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 15 Dec 2009 03:22:05 +0000

Martin Rex wrote:
> protection against this at the TLS protocol level.

That is not correct. There are two cases, strict clients (that want to
connect only to patched servers), and lenient clients.

For a strict client, the requirement that patched servers be both
version-tolerant and extension-tolerant allows the client to completely
abandon any fallbacks. This is an unqualified Good Thing.

For a lenient client, the MCSV tells the server that the client is
patched. Then,

 - if the server is also patched, it sends back the extension in the
   ServerHello. An attacker can replace this message, but if it
   does then the Finished verification will fail (provided that part
   of the protocol remains sound). If the client receives this message,
   then it knows that it is safe to reconnect without any fallbacks,
   and without risking any interoperability problem.

 - if the server is not patched, then we're no worse off than before.

In other words, even for lenient clients, this scheme protects against
rollback attacks when the server is patched. Whether it is sufficient to
prevent a particular future weakness found in TLS will depend on what
part of the protocol the weakness occurs in. If it allows the attacker
to replace handshake messages, then it won't be prevented, but if it is
any other kind of attack, and is dependent on the TLS version, then the
attacker will not be able to force a version rollback between a client
and server that have both been patched against the renegotiation flaw.

[...]
> sent a more feature-rich ClientHello.

If the server only supports SSLv3, then no rollback attack is possible --
the negotiated version will be SSLv3 and that's the best we can do.

> In probabilistic terms, it

I don't see your point. The goal is that the negotiated version is the
maximum that both the client and server can support. The problem is that
with fallbacks, that goal isn't necessarily achieved. With Yngve's
suggestion, it will be achieved between updated clients and servers.

> should be completely removed from the specification (i.e. MUST be ignored

I agree, but that's completely independent of Yngve's proposal.

> renegotiation (server-side).

"Backward-interoperable renegotiation" is an insecure distraction.
I don't value this as a feature of any solution; actually I think it's a
misfeature. However, it is not incompatible with preventing version
rollbacks between updated clients and servers.

> completely up to your implementation to ensure that.

As typically implemented, it is a security hole waiting to happen.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 15 Dec 2009 03:28:41 +0000

Yngve Nysaeter Pettersen wrote:
> If the server does not support renegotiation then it might not support
> the extension, but my proposal is that it MUST be TLS Extension
> *tolerant*. I am however suggestion, optionally, that supporting the
> extension should be a MUST in patched servers.

It has to be a MUST. Otherwise,
 - strict clients will unnecessarily abort the handshake when they
   don't see the extension.
 - lenient clients won't know to reconnect, so rollback attacks are
   not necessarily prevented.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 15 Dec 2009 03:46:02 +0000

> to the TLS renegotiation vulnerability.

How should a client prevent such a downgrade attack, in the presence of
version-intolerant servers?

The renegotiation vulnerability provides an opportunity to get rid of
fallbacks in the medium term, because there will be strict clients that
only connect to servers patched against that vulnerability. If *all*
servers that are patched against the vulnerability are version-tolerant,
then such clients don't need fallbacks.

That leaves lenient clients that currently do not connect with their
highest supported protocol version, for which Yngve's suggestion of
reconnecting with the highest supported version is relevant. If you
have an alternative proposal that achieves the same security properties
for such clients with comparable efficiency and interoperability, let's
hear it.

> and can not possibly work at the TLS protocol level.

The clients that perform fallbacks are not working entirely at the
TLS protocol level anyway.

> restarts the handshake mid-way),

Is that compliant to the spec? It sounds no simpler than dropping the
connection and reconnecting, and could cause its own interoperability
failures.

> or successfully complete the handshake and renegotiate immediately
> after with better features.

That involves greater overhead and more round-trips.

> require apps-level support for this.

The only case in which such a reconnection would occur is where such
apps-level support already exists. No-one is suggesting adding
fallbacks to implementations that do not already use them.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 15 Dec 2009 03:51:36 +0000

> in charge of both sides for SGC.

Indeed, when MS SGC was first implemented, it completely broke
interoperability:

<http://support.microsoft.com/kb/249863>

# Web clients may fail to connect to Web sites that use Server Gated
# Cryptography (SGC) for strong encryption when a secure connection is
# required. If either the Internet server or Web client is running Microsoft
# products, then the connection may fail. If the Internet server and Web
# client are both running Microsoft products, then no problem occurs.

I don't know how this was fixed, but it seems as though encouraging
the use of an MS SGC-style protocol in other implementations is just
asking for more interoperability problems.

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 15 Dec 2009 12:30:33 +0100

>    not necessarily prevented.

I am referring to supporting (recognizing) the RI extension in the Client  
Hello. Maybe that wasn't clear enough.

-- 
Sincerely,
Yngve N. Pettersen

---

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

> such a refusal must be considered an attempt to perform a version rollback

If you really wanted to retrofit a version rollback attack into the
installed base along with secure TLS renegotiation, then I would
suggest to piggy-back the information about the highest supported
protocol version of the server into the (currently empty)
TLS extension Server->Client on the initial handshake.

The client (like your favorite browser) can then decide whether it
cares and how it cares about not having negotiated a protocol
version that it believes to be preferable (you indicated to
have fallback re-connect logic, so your browser could even
automatically retry instead of nagging the user).

-Martin