Subject: [TLS] Non-extension solutions (requirements)

From: Marsh Ray <[email-masked]>
Date: Sat, 14 Nov 2009 21:46:44 -0600

The current draft-rescorla-tls-renegotiation represents a good solution,
at least from the theoretical perspective. However, when one begins to
consider the practical difficulties it is encountering in actual
deployment it becomes clear that it is not likely to be a good solution
in practice. It is for this reason that we need to look at other
proposals with the aim of providing the most compatible and easiest to
implement fix on existing systems.

This means:

=== R5. Not using an extension to implement the fix.

Currently there are no examples of extensions used in a critical role
between interoperable systems, even where there would be significant
gain (financial and otherwise) from their use (e.g., SNI). An urgent
security-critical bug fix is absolutely not the place for blazing new
trails.

It appears that somewhere between 20% and 40% of current SSL/TLS traffic
is between systems that either preferred not to (or could not) use TLS
1.0 with extensions.

=== R6. The fix must work for SSLv3.

One source measured 22% of current SSL/TLS traffic still over SSLv3, and
other sources of data have tended to confirm that. This is far too large
a group to ignore, or expect to "just upgrade".

Even software that does support newer versions of the protocol will
often fall back to SSLv3 at the first sign of trouble. Any fix which
does not address SSLv3 can simply be bypassed by the attacker

=== R7. The fix must be easy to merge across existing code branches.

One vendor has an installed base of hundreds of millions of systems with
SSL/TLS stacks designed before TLS extensions were well-defined or
relevant. They and other vendors also have many legacy code branches
they will have to patch.

The main goal of these requirements is to restore the functionality of
TLS on as many systems as possible, as quickly as possible. Solutions
need to take into account development and testing processes,
particularly those at vendors with a large installed base and many
product lines.

=== R8. The fix must facilitate testing.

Solutions with the potential to simplify testing processes could
represent the biggest win in terms of time.

For example, fixes which rely on extensions could represent more work
for a test group that is currently set up for product lines that don't
use them.

=== R9. Must interoperate perfectly with unpatched systems.

If the patch causes disruption in trial deployments, it will likely not
get a second look. Most sites will just patch to disable renegotiation
entirely.

-------

Restating some previously accepted requirements/features:

=== R1. Restores the security guarantee of continuity-of-identity when
both endpoints have been patched.

May be able to provide some benefits when one of the endpoints has been
patched.

=== R2. Supports secure and compatible modes.

Secure mode - endpoint will not allow any potentially dangerous
connections with unpatched remotes.

Compatible mode - endpoint may be willing to take some risks with an
unpatched remote.

This requirement is to allow for a transition period for everyone to
patch and ultimately migrate to secure mode. The actual timeline is for
admins and vendors to work out individually.

=== R3. Free of IPR claims.

Oh it happens.

=== R4. Must indicate presence of patch in plaintext.

Intrusion detection, network auditing, and firewall tools will benefit
from seeing that the fix is applied in the unencrypted part of the
initial handshake.

For most sites, this is perhaps the only advantage the patch has over
disabling renegotiation. Without it, many minimally-inspecting firewalls
will be configured to simply drop all renegotiations.

===

Discuss, suggest, etc. please.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Nov 2009 13:18:33 +0200

At Sat, 14 Nov 2009 21:46:44 -0600,
Marsh Ray wrote:
> in practice.

That's not at all clear to me.

> It is for this reason that we need to look at other

I don't find this convincing at all.

There's a huge difference between using an extension to implement
something which we know needs changes on both sides right now and
which we want to break if both sides aren't changed and using
an extension to roll out an incremental feature that's a nice
to have (i.e., name-based virtual hosting.)

I think it might be useful to go back to first principles:

1. Servers which do not wish to do renegotiation can protect themselves
   without any change to the TLS protocol or to the client. I think
   it's pretty clearly desirable to have such servers continue to
   work with downrev clients.

2. Any fix must cause renegotiation between upgraded and unupgraded
   agents to fail. This is true whether the fix is explicitly signalled
   via an extension, explicitly signalled via a cipher suite/version,
   or unsignaled, such as by extending the finished message hash to
   incorporate earlier handshakes/incorporating previous finished
   messages into the PRF.
   
   Thus, the minimal change is not to change initial negotiations at
   all but simply to change renegotiations. This is quite possible
   with RI simply by not sending it on the initial negotiation. Of
   course, sending it on renegotiation will cause interoperation
   failure with vulnerable servers, but that's the desired outcome.

3. If we only make the minimal change, then clients will not be able
   to determine whether they are connecting to a vulnerable server
   even if they have no intention of renegotiating.  If we want them
   to be able to do so, then it's most natural to have upgraded
   servers behave differently on the initial negotiation.

   I should add that I don't really think this functionality is that
   useful. Because the simplest fix is to simply disable
   renegotiation, many servers will do just that, regardless of how
   compatible the client's offer of a newer version is. I find it
   highly implausible that people who are currently running OpenSSL
   0.9.7x are going to suddenly install a version which responds to a
   fake cipher suite by upgrading to TLS version 1.3! Thus, any client
   which warns on failure of the server to acknowledge being upgraded
   is going to be throwing off a huge number of false positives.

   Per (1) I think it's desirable to not have this functionality break
   un-upgraded clients. Similarly, it should be possible for upgraded
   clients which don't care about whether servers are upgraded to be
   able to interoperate with such servers (which, again, will dominate
   for the foreseeable future). As I indicated above, this is trivially
   possible with RI simply by not sending it on the initial negotiation:
   there's no interop problem but the client doesn't learn anything. And
   again, RI can always be used on subsequent negotiations.

   For clients who care, there are a number of mechanisms we could use to
   provide this functionality, including:

   (a) Send RI on the initial handshake.
   (b) Send something else (e.g., a fake cipher suite) on the initial handshake.
   (c) Have the server send something unsolicited, e.g., a fixed portion of
       the ServerRandom.

   The major problem (to the extent it is a problem) with offering RI on
   the initial handshake is that it may cause interop failures with some
   servers which don't support TLS extensions properly. In order for this
   to be an issue however, you have to believe that:

   (1) The client wishes to be able to detect that servers have not
   been upgraded.
   (2) The client isn't going to outright fail when it encounters
   such servers.
   (3) The client can't deal with a reconnect given (2) and (3).

   I don't really find this set of assumptions very plausible. Clients
   which care enough to actually probe the server to determine if it
   has been upgraded need to do something with that information. If
   they're going to outright fail then there's no problem here: they
   might as well fail when the server chokes on the extension as fail
   when they detect that the server isn't upgraded.  If they're going
   to pop up a warning dialog (a bad idea in any case because of
   warning exhaustion) then I don't see that a reconnect is that big a
   problem, since they've already had to engage a bunch of application
   logic. And remember that this question *only* applies to servers
   which don't properly handle extensions. Given that the fix to do so
   is trivial (just ignore data after the ClientHello), and those
   servers are most likely vulnerable in any case, I really don't see
   that this is a major issue.

4. The other argument offered in favor of avoiding extensions is
   that we want to be able to provide upgraded SSLv3 implementations.
   I'm unconvinced that there are a significant number of 
   applications which:

   (1) Can't use TLS.
   (2) Do renegotiation.
   (3) Are going to upgrade their stacks to support some new 
   secure renegotiation thing change.
   (4) Won't just upgrade to TLS.
   
Certainly all the major stack vendors have had TLS support for a very
long time. For instance, you have to go back to before OpenSSL even
existed to find a version of SSLeay that is SSLv3 only. And if you do
support TLS, the effort of just implementing doing this extension is
really not significantly greater than the other proposed fixes.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Nov 2009 13:18:45 +0200

(1) Can't use TLS.
   (2) Do renegotiation.

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 15 Nov 2009 12:35:58 -0800

> is between systems that either preferred not to (or could not) use TLS

The same logic kept some browsers from disabling SSLv2 for years.
When SSLv2 was finally dropped, there were numerous complaints received
from corporate types complaining that the action had been "premature".

There will ALWAYS be companies who procrastinate as long as possible on
any software upgrades.  Let's not let them dictate how we fix TLS.
Let's do the right thing here, even if it means forcing some to upgrade.

> === R6. The fix must work for SSLv3.

What does that mean?

- Does it mean devising a "fix" for SSLv3 that allows patched but still
SSLv3-only clients to safely renegotiate with patched but still SSLv3-only
servers?

- Does it mean devising a way for patched but still SSLv3-only clients
to detect that they are connecting to unpatched and vulnerable SSLv3 only
servers, and refuse to connect with them, on the grounds that doing so
may be seen by that server as a completion of a renegotiation?

> a group to ignore, or expect to "just upgrade".

That's what they said about SSL2.

> does not address SSLv3 can simply be bypassed by the attacker

I think you're assuming that the browsers will decide that continued
interoperability with the old vulnerable servers is more desirable that
being able to claim that their browsers are invulnerable to this attack.
I tend to assume the opposite.

I believe that one of the reasons that browsers (at least one browser) have
been willing to "fall back" has been the perception that TLS 1.0 did not
offer significantly (or perhaps, ANY) greater security than SSL 3.0), and
so falling back from TLS 1.0 to SSL 3.0 was not perceived as a loss of
security.

Now, that perception may be changing (may have already changed), a LOT.
If so, it may be that the time for the fall back is hastily ending.
Let's not assume that it isn't.

> === R7. The fix must be easy to merge across existing code branches.

Sorry, that presumes reasonable development practices have been followed
in the creation of those branches.  I think this is at best a highly
desirable thing, not a requirement.

> === R9. Must interoperate perfectly with unpatched systems.

Again, what does that mean?
Does it mean that a patched client connects without hesitation to an
unpatched and vulnerable server, thereby falling victim to the attack?

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 14:56:01 -0600

Nelson B Bolyard wrote:
> [...]  Let's not let them dictate how we fix TLS.

I was with you on that 100% until a few days ago.

In this case, there is no 'leverage' with which to push for a proper
upgrade: approximately 99% of sites will just disable renegotiation
entirely.

> SSLv3-only clients to safely renegotiate with patched but still SSLv3-only

Yes.

> may be seen by that server as a completion of a renegotiation?

Yes.

> being able to claim that their browsers are invulnerable to this attack.

Mainly that the fix has to be patchable at the TLS library level and
can't require application code changes.

> desirable thing, not a requirement.

Yeah, it's not the kind of thing that makes a good functional
requirement when designing a new system.

However, the reality is that a fix that requires a serious porting
effort is going to take longer to deploy than one that can be done with
simpler code change and this needs to be taken into consideration when
choosing between alternatives.

> unpatched and vulnerable server, thereby falling victim to the attack?

It means that whatever fix we propose on to the public has to work
seamlessly. My guess is that we have one shot at delivering something in
a window that ends quite soon. If the patch makes a first impression at
breaking one in ten connections, most admins will simply choose the
patch which disables all renegotiation. Once that happens, it's gone for
good, yet a lot of important systems depend on it.

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 15 Nov 2009 13:06:14 -0800

>    work with downrev clients.

Agreed.

>    agents to fail. 

Ummm, remembering that a client's initial handshake may be a server's
renegotiation, I think that requirement needs to say that

     Any fix must cause any handshake between upgraded and non-upgraded
     agents to fail, when that handshake is seen as a renegotiation by
     the server, whether it is seen as an initial handshake or as a
     renegotiation by the client.

>    This is true whether the fix is explicitly signalled

Are there clients who really want to remain vulnerable?

>    even if they have no intention of renegotiating.  

I believe clients (browsers, in particular) will not be able to claim
they are invulnerable, and will be accused of remaining vulnerable, as
long as they are not able to make that determination.

> really not significantly greater than the other proposed fixes.

I agree.  I don't hear any customers of my employer demanding a fix that
avoids going to TLS.   The customers either
a) have been avoiding any and all updates entirely for a long time, or
b) upgrade pretty regularly as "security updates" come out, and are
already using TLS-capable stacks.

If anything finally motivates those customers with the very old software
to finally update their software, the only choices available to them will
all include TLS-capable stacks.  They will still have the option of
enabling only SSL3, in which case renegotiation will be disabled.  If they
need renegotiation, they need only to enable TLS, and Voila.

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 22:30:44 +0100 (MET)

> The same logic kept some browsers from disabling SSLv2 for years.

Flawed comparison.  SSLv2 known security problems.
SSLv3 does not.  SSL renegotiation has a problem, but across the board
from SSLv3 all the way to TLSv1.2.

> Let's do the right thing here, even if it means forcing some to upgrade.

That would be extremely poor engineering.

We are perfectly able to provide a solution that can be applied to
all protocol versions out there, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2.

Designing the fix so that adding it to SSLv3 is much harder than
for TLSv1.2 is irresponsible.

> SSLv3-only clients to safely renegotiate with patched but still SSLv3-only

It means that secure renegotiation should also be used when both
peers negotiation protocol version 0x03.0x00.  If the fix does not
do that, then the fix is not a fix, but another failure.

> I tend to assume the opposite.

This is ridiculous.

Browser vendors added the fallback renegotiation not because they
had too much time on their hands.  They wanted to use TLS extension SNI
or newer TLS versions and encountered severe interop issues.

The TLS WG can easily devise a fix for secure TLS renegotiation that
will work even during the fallback, and that can be hotfixed into the
entire installed base immediately with an extremely low probability
of breaking interoperability.

I also would try to get a client-side fix to our customers in 2-3 weeks
if it does NOT use extensions. (we don't support renegotiation on the
server, so adding the signaling to the initial Handshake is all I
have to do for the server).

If the TLS WG ships the TLS extension RI, then it will be several months
before I will be shipping anything for the client side, because I first
will need to think about solutions for the interop problems that will
arise and how to make the client-side behaviour configurable (which
requires changes to all applications).

An extension-less Client->Server Signaling on initial handshake is
something that I would risk shipping immediately without a configuration
option, taking care about interop problems when they're reported.

> Now, that perception may be changing (may have already changed), a LOT.

Huh?  What are you refering to?
Those that moved to newer implementations and started to rely
on renegotiation in their Website structure are now the ones
who suffer the most.

> desirable thing, not a requirement.

That is a pretty significant and realistic requirement.

In particular, if you have several different code lines providing
different protocol levels of TLS, then a fix where 90% of the code changes
is the same for all code lines is much better than one that needs to
be individually developed for every codeline.

Therefore devising the fix so that is requires minimal changes for
the oldest implementation affected by this protocol defect (SSLv3)
is the most reasonable approach to fixing that defect.

> unpatched and vulnerable server, thereby falling victim to the attack?

It means that if the fix is designed in a fashion that it can be
used by clients at all protocol levels, even SSLv3 immediately with
an extremely low probability of breaking existing usage scenarios
(and that DOES INCLUDE servers that are still unpatched), then
we will see by far the quickest adoption of the update.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 13:48:28 -0800

> Are there clients who really want to remain vulnerable?

Um, strawman?

The minimal change is helpful for clients that want to remain  
interoperable with servers that haven't been updated yet, because

- some servers wouldn't really have to be updated because they don't  
support renegotiation in the first place;

- atomically updating all clients and servers isn't possible;

- the attack is irrelevant for opportunistic-encryption scenarios --

if these clients *accept*, as trade-off, that they'd also continue to  
be able to engage in insecure connections (when connecting to insecure  
servers).  This doesn't mean that they *want* to be vulnerable.  It  
doesn't even imply that they necessarily *are* vulnerable (this  
depends on what the higher protocol layers are actually doing with the  
TLS connections, and what servers they open connections to).

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 14:03:54 -0800

> does not address SSLv3 can simply be bypassed by the attacker

I don't agree that the fix must fully work for SSL 3.0.

A fix that simply disallows renegotiation for SSL 3.0 (while updating  
the renegotiation protocol for TLS 1.0 and later -- or also for the  
"SSL 3.0 with TLS extensions" hybrid) could not be bypassed by the  
attacker.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 23:42:39 +0100 (MET)

> to have (i.e., name-based virtual hosting.)

If we provide the fix wrapped in a TLS extension, then updating
the installed base will require careful planning, because clients
sending TLS extensions will cause interop problems in existing
usage scenarios.

If we design the fix in a way that the risk of interop problems
in existing usage scenarios is extremely low, then the end users
do not have to perform careful update planning to make sure all servers
are updated before the first client is updated.

This interop interlocking is a severe problem because TLS is used
on the internet and usually you connect to other people's servers
as well, not just your own.  Having to plan you update procedure
for your own clients&servers is already painful, but having it
to synchronize it with the update of all the other servers out
there that you're using would be a royal PITA.

There WILL BE a transition period, and ignoring the problems that
a solution will create during that transition period is a BAD IDEA.

Am I really the only one who thinks that requiring the
TLS extension RI band-aid throughout eternity instead of adding
the fix where it belongs--into the base protocol makes the
protocol more complex than necessary and looks weird.

>    servers behave differently on the initial negotiation.

The "minimal" change should include signaling, of course, but
work entirely without extensions, in particular without sending
the verify_data over the wire, because that is entirely unnecessary
in order to protect the renegotiation.

Why should we send the stuff over the network when we know exactly
that it is unnecessary and just compilicates the protocol, complicates
implementations and wastes network bandwidth?

>    fake cipher suite by upgrading to TLS version 1.3!

Why are you talking about TLS v1.3 here?  I have not seen anyone
suggesting upgrade to TLSv1.3.

I'm asking to stay on SSLv3 and/or TLSv1.0 with a TLS renegotiation
fix.

TLSv1.3 was only mention in the context that it should no longer
support the old TLS renegotiation at all, no further signalling
required.

>    (c) Have the server send something unsolicited, e.g., a fixed portion of

There is absolutely no need for the server to send anything unless
the client has clearly indicated that it will understand that something
perfectly well!  In that respect, there is no difference between
RI and my proposal.

>    has been upgraded need to do something with that information.

The fact that there are Browsers that actually "probe" indicates that
we have non-negligable interop problems with TLS procotol version and
TLS extensions.

The largest part of programmatic clients and Browsers that are not
bleeding-edge do NOT probe and neither want to probe servers.
They just want to signal servers that they are capable of secure
renegotiation.

And they want to be able to signal that to the entire world without
having to fear that a fraction of the servers that these clients
talk to will choke and close the connection.

This problem will be particularly severe during the transistion period
between today (where no patched servers exist) and somewhere late next
year, when most servers will have been patched.

Breaking existing usage scenarios out of negilgence is poor engineering.

Not just for software vendors shipping updates to the customers,
but also for and IETF working group trying to fix a protocol defect.

>    I'm unconvinced that there are a significant number of 

 - there definitely are.
 - if the solution for the TLS renegotiation weakness does not
   describe how to use it on connections that are negotiated
   with protocol version 0x03,0x00, then such a solution is a failure
 
>    (2) Do renegotiation.

They ususally don't use reneogitation on the server side.
However they can do it on the client side, therefore it is extremely
important that the solution specifies how to renegotiate securely
with protocol version 0x03,0x00

>    secure renegotiation thing change.

yes, everyone that has shipped SSL or TLS and charges for maintenance
is going to fix his code.

>    (4) Won't just upgrade to TLS.

There are many more implementations of TLS than just those that
you know.  And since TLS specifies only wire-formats and protocol,
but nothing about API and credentials management, there is _NO_
simple plug'n'play between TLS implementations of different vendors.

The option "to just upgrade" simply does not exist for a number
of consumers of TLS, since their implementation exists only for
the particular protocol version that they're using.

And even those who do use an implementation from one of the
well-known providers -- those who use it in productive environment
can not simply plugin the most recent release of the software,
because it is going to affect at least some of the actively
used scenarios.

The TLS renegotiation vulnerability is a flaw in the protocol
that can be fixed entirely within the base protocol and the
TLS implementation and with a minimal risk of affecting
existing usage scenarios, in particular during the transistion
period.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 16:51:33 -0600

> I don't agree that the fix must fully work for SSL 3.0.

There is currently a massive amount of SSLv3 traffic. Sure, much of it
is because people aren't being proactive about upgrading. A significant
amount of it we must assume is because there are real difficulties in
upgrading.

> the renegotiation protocol for TLS 1.0 and later -- or also for the "SSL
> 3.0 with TLS extensions" hybrid) could not be bypassed by the attacker.

If there are client cert credentials in the initial handshake, those
could be stolen and forwarded to another server.

Be careful what you ask for, for many sites it is far easier to just
disable renegotiation entirely than to get 100% off of SSLv3 in the
timeframe of a security fix.

There are entire business, development models, and security
infrastructures built on https renegotiation. We mustn't fail them by
allowing the majority to effectively deprecate what is a legitimate part
of the protocol.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 14:52:17 -0800

> a solution will create during that transition period is a BAD IDEA.

I fully agree.

> protocol more complex than necessary and looks weird.

As I said, the approach of using the previous Finished messages as  
"virtual handshake message" (I think that's the term you used) for the  
new verify_data looks good.  This requires some signal for current  
protocol versions, and no additional signal for a newer protocol  
version where this would be standard.

This signal could be a TLS extension -- arguably band-aid, but not  
needed throughout eternity.  Furthermore, as this would be a *fixed*  
TLS extension (no content required), this should be easy to add even  
to implementations that don't really support TLS extensions: For the  
client side, it's an entirely fixed value to append to the Client  
Hello; for the server side, it's a fixed value to search for in the  
client_hello_extension_list (and a fixed value to append to the Server  
Hello).

Bodo

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 23:56:41 +0100 (MET)

> "SSL 3.0 with TLS extensions" hybrid) could not be bypassed by the  

It is completely trivial to design the fix so that it works
for ALL protocol version SSLv3->TLSv1.2

It would be unreasonable and irresponsible to design the fix in a fashion
that is hard to apply to SSLv3 or to remain entirely silent in the
solution how the fix works for TLS session negotiated with protocol
version 0x03,0x00.

Most of the installed base using 0x03,0x00 is _not_ broken.
The servers that are using renegotiation, and most of these use
newer TLS implementations, are the ones that are vulnerable.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 17:05:02 -0600

> protocol more complex than necessary and looks weird.

I think so. :-)

If RI gets deployed as hello extensions and it works, don't mess with it.

Just because the sub-structure's name has the word "extension" doesn't
make it a band-aid or even not part of the base protocol. Protocols have
a long tradition of defining "required options" and "optional options".

On the other hand, if you're saying something deeper (say about mac
calculation or whatever) needs to change that could be an interesting
point, but don't detract from it by mixing it up with objections to the
"extension" label.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 15:08:51 -0800

On Nov 15, 2009, at 2:51 PM, Marsh Ray wrote:

> There is currently a massive amount of SSLv3 traffic.

How much of this does involve renegotiation, though?

For current SSL 3.0 traffic involving renegotiation, how much of this  
is SSL 3.0 just because newer client or server software hasn't been  
*installed* in a while?  A software upgrade would be needed anyway for  
anyone hoping to use a new SSL 3.0 renegotiation feature.  Where  
protocol versions newer than SSL 3.0 are currently available anyway  
(just not installed), no new SSL 3.0 feature would be needed.  For  
software packages where even the *current* version only has SSL 3.0  
(and supports renegotiation), yes, a fix that works for SSL 3.0 would  
be nice.  The mere amount of SSL 3.0 traffic doesn't tell us anything  
about how many these are, though.

> Sure, much of it

I can't really believe that the upgrade to a modified SSL 3.0 (with  
secure renegotiation) would be much easier in these cases, though ...

Anyway, a simple protocol fix (using extensions without content, say)  
should work reasonably well even with SSL 3.0

>> "SSL

How so?  The client supposedly will authenticate the server it is  
sending a certificate to (and to the extent that it matters, "It is a  
fatal handshake_failure alert for an anonymous server to request  
client identification" according to the specs).

Bodo

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 01:33:20 +0200

At Sun, 15 Nov 2009 14:56:01 -0600,
> good, yet a lot of important systems depend on it.

I'm confused: is anyone proposing a patch on the server which would 
break *any* connections? The only breakage I can see is that some
clients will be unable to operate with old servers. This doesn't
seem to have the effect you suggest at all.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 01:29:43 +0200

At Sun, 15 Nov 2009 13:06:14 -0800,

Agreed.

> Are there clients who really want to remain vulnerable?

I'm sure there aren't, but unless I'm missing something for the foreseeable
future there is no way to avoid that while still actually being
compatible. The way I mentally model this is like a software vulnerability
in a popular server, e.g., OpenSSL. Until the server fixes, the attacker
can subvert the server and attack the client's connection and there's
really no way for the client to unilaterally defend without fingerprinting
the server, which is in general impractical.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 01:20:01 +0200

At Sun, 15 Nov 2009 22:30:44 +0100 (MET),
> option, taking care about interop problems when they're reported.

To be clear, this is what I am proposing.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 17:48:13 -0600

Eric Rescorla wrote:
> break *any* connections?

Well, yes. But, I'm not sure why it matters if the patch is made on the
client or the server.

A fix that doesn't address SSLv3 gives many users and admins a choice
between being vulnerable or "breaking the connection".

Apparently some servers "break" when they see a hello extension.

> The only breakage I can see is that some

Any proposed fix in which "some clients will be unable to operate with
old servers" is DOA at most sites because there is a painless
alternative which does not (disabling all renegotiation).

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 02:09:16 +0200

At Sun, 15 Nov 2009 17:48:13 -0600,
Marsh Ray wrote:
> Well, yes.

Really? Which fix has this property? Every single fix I have seen
proposed can be safely applied to any server (though of course
they necessarily have the property of breaking renegotiation
with old clients, but that's the intended behavior.)

> But, I'm not sure why it matters if the patch is made on the
> client or the server.

Because you keep talking about "sites" but in most sites the server
operator gets to control just that, the server, and more or less takes
their clients as they find them.

The server operator's choice has far more to do with the tradeoff
between having insecure renegotiation or secure renegotiation but
broken compatibility with the vast pool of unpatched clients. AFAICT
the only setting in which that decision is at all affected by our
choice of approach is if one side is running SSLv3 *and* the
maintainer of the SSLv3 stack would apply one fix but not another.
What actively maintained stack is SSLv3 only?

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 17:36:59 -0800

> will be configured to simply drop all renegotiations.

I disagree that this is a definite requirement.  In my proposal there
are NO changes to the bits on the wire.  Therefore it is impossible
for a MITM to mess with the handshake in any way that it can not
already.  I believe that this is a worthy goal.  Adding extensions or
magic ciphersuites are all possible new points of attack for the MITM.

Changing the Finished message calculation even for initial handshakes
allows clients and servers both to complete the handshake without worry
of being attacked.  A failure would imply either:

    - a patched client connected to an unpatched server
    - the server is patched but a MITM was causing trouble

I believe these are precisely the two failures we want by default.

With the RI extension, a client that wants to protect itself from an
unpatched server needs to abort the handshake before sending its
Finished message.  This is the key -- neither side will know for
certain that an attack took place since Finished messages are not
exchanged, and can't be if you want to remove the possibility of an
attack.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 03:09:13 +0000

> alternative which does not (disabling all renegotiation).

Huh? Any server that upgrades is not one of the "old servers" that will
break. That is necessarily the case because the upgrade (at least for
Eric's draft) requires the server to be extension-tolerant. So the
fact that there are other broken servers, does not influence any
particular server operator's decision to upgrade.

On the client side, disabling renegotiation is unnecessary, because
it's possible (in the case where you still want the client to connect
to unpatched servers) to only send the extension when renegotiating.
And if you don't want the client to connect to unpatched servers, then
there's no interoperability problem because all patched servers will
be extension-tolerant.

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

---

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

> exchanged, and can't be if you want to remove the possibility of an

I don't see why that is a problem. Being able to prove that an attack
took place (or to distinguish an attack from, say, line noise or any
of many possible implementation errors) was not a design goal of TLS,
and the protocol doesn't achieve that for numerous reasons. It is
hard to see how a secure channel protocol could possibly achieve this
goal, for active attacks.

---

From: Chris Newman <[email-masked]>
Date: Mon, 16 Nov 2009 18:16:32 -0800

> - the attack is irrelevant for opportunistic-encryption scenarios --

I disagree with this assertion.  Opportunistic TLS for SMTP-relay is highly 
problematic.  I would recommend sites disable STARTTLS for SMTP relay on 
port 25 until they patch their TLS stacks.  I would keep STARTTLS enabled 
for SMTP submission (RFC 4409, where a server is configured to require SMTP 
AUTH for all submissions).

In the email standards world, we have been promoting the idea that SMTP 
submission (RFC 4409) and relay (RFC 5321) need to be treated as 
independent services with independent configuration (RFC 5068).  This is 
yet another case where we were correct.

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Nov 2009 10:35:55 +0100

Chris Newman <[email-masked]> writes:

> I disagree with this assertion.  Opportunistic TLS for SMTP-relay is
> highly problematic.  I would recommend sites disable STARTTLS for SMTP
> relay on port 25 until they patch their TLS stacks.

How does the TLS reneg attack work for SMTP?  I haven't seen it
explained anywhere, and I don't easily see how it applies.

I don't think it is wise to recommend disabling TLS without explaining
why.

Btw, it is also not clear that the TLS reneg bug even applies to all TLS
stacks -- for example GnuTLS requires assistance from the application to
do renegotiation, and most applications do not provide that assistance
with the result that TLS reneg cannot succeed.  So these client/servers
using GnuTLS are not vulnerable to the TLS reneg problem.

/Simon

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 17 Nov 2009 18:57:30 +0000

> I don't think it is wise to recommend disabling TLS without explaining

I agree completely. In fact I can't see how disabling TLS can possibly be
an improvement, if the alternative is a cleartext connection.

> using GnuTLS are not vulnerable to the TLS reneg problem.

That's a bit of an oversimplification:

 - If a client is using a stack that does not support renegotiation, it
   is still vulnerable on connections where the server will accept
   renegotiation.

 - If the server is using a stack that does not support renegotiation,
   it can still be vulnerable on connections where the client will
   accept renegotiation (subject to some other conditions).

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Nov 2009 20:15:20 +0100

>    accept renegotiation (subject to some other conditions).

Sure, but in your situations any security problem lies in the non-GnuTLS
side right?  It is the non-GnuTLS peer (if any) that needs to be
patched, either to disable reneg, or to implement a secure workaround
(in which case the GnuTLS peer needs to support it too for things to
work again).

This is why I believe the short-term fix to disable reneg is needed in
OpenSSL is useful (because it, as far as I understand, it does reneg
without asking the application) but the same fix is not useful for
GnuTLS.  If there are any applications that use rehandshake with GnuTLS,
it is simpler and more appropriate to patch those application.  Of
course, if it turns out that a majority of GnuTLS applications are
affected by this, it makes sense to fix it in GnuTLS to give protection
by default.  But this does not appear to be the case so far.

Yes, this is a complex argument, so additional thoughts into what the
GnuTLS team should do is appreciated.

/Simon

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 17 Nov 2009 21:39:22 +0000

> (in which case the GnuTLS peer needs to support it too for things to

Yes. I was just commenting on the statement that "*client/servers using*
GnuTLS are not vulnerable", which could be misinterpreted by people less
familiar with the attack.

> it is simpler and more appropriate to patch those application.

I'm not sure about that. If an OS distribution has several applications
linked against the same shared GnuTLS library, then it might make sense
to patch GnuTLS. (I'm not sure whether this is a common deployment scenario
for GnuTLS; it is for OpenSSL.)

But it seems as though a more complete fix will be available pretty soon,
anyway.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Nov 2009 22:58:39 +0100

> familiar with the attack.

Right.  The "these" was significant generally speaking.  However, it
appears as if your application use GnuTLS in both client and server, and
the application does not have code to do TLS reneg (which appears to be
what the majority of all GnuTLS applications out there does) you are not
vulnerable.

> for GnuTLS; it is for OpenSSL.)

Right, but few (if any) applications linked dynamically with GnuTLS
appears to be vulnerable.  I believe one needs to look at each of the
applications individually.  If there is a pattern in them that they are
buggy in the same way, the problem should be fixed in GnuTLS.  But if
there is no pattern in the problems, or even any vulnerable applications
at all, it does not make sense to do anything in GnuTLS.

This investigation has been done for OpenSSL, and for it there is a
clear pattern that applications are vulnerable, and a fix was made for
OpenSSL.  But the same pattern doesn't seem to exists in GnuTLS
applications.

> But it seems as though a more complete fix will be available pretty soon,

Right, but I'm not sure it makes sense to release a security upgrade of
GnuTLS with that extension.  Doing so would not fix any known vulnerable
application, or we would have to act today by disabling tls reneg for
that particular application while we wait.  So the extension would be
like any new feature in a future stable branch.

/Simon

---

From: "Rob P Williams" <[email-masked]>
Date: Tue, 17 Nov 2009 18:30:52 -0500

> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simon Josefsson
> Sent: Tuesday, November 17, 2009 4:59 PM
> To: David-Sarah Hopwood
> Cc: [email-masked]
> Subject: Re: [TLS] Non-extension solutions (requirements)
> 

Hopefully - that security upgrade is already under development.

Don't the unknown applications that are using GnuTLS deserve immediate 
protection too?

You cannot assume that your peer's version of any application is using a
specific TLS stack.

You cannot prove that you are talking to a peer that is immune to
this attack. 

GnuTLS needs the extension*. Any TLS implementation that doesn't move 
forward with the extension will remain vulnerable.

* or whatever the IETF agrees upon.

--
rob | Software Developer
Certicom Corp. | A susbidiary of Research In Motion Limited

main | +1 905-507-4220
direct | +1 905-501-3887

[email-masked]
www.certicom.com

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.