Subject: [TLS] To extend or not to extend

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 15 Nov 2009 03:13:01 -0800

We need to close on this issue.  To summarize the RI proposal (the draft
submitted last week) has the following properties in various situations

A. The RI proposal works fine if both client and server are patched.  

B. The RI proposal works fine if the client is not patched and the
server is (the server ends up disabling re-negotiation).  

C. The RI proposal works fine if the client is patched and the server is
not, if the server is implemented correctly. 

D. The RI proposal works fine if the client is patched and the server
does not implement the SSL 3.0 and the TLS 1.x specs correctly (barf if
they see an extension) and the client desires to implement an secure
policy and disallows connections to non patched servers

E. The RI proposal has an issue if the client is patched and the server
does not implement the SSL 3.0 and the TLS 1.x specs correctly and the
client as a lenient policy which allows connection to insecure servers.
In this case the client would have to implement some fallback logic
(reconnect without extensions) to deal with broken servers.  This logic
is well-known, but it leaves a roll-back attack open.  This can be
plugged by using the proposed ciphersuite signal only in the case where
extensions cause a handshake or connection failure.  The fallback
cipher-suite signaling for RI to prevent rollback extends TLS in an
unexpected way, but this is limited only to the case where we have to
deal with broken implementations.  

Situation E is one that we expect to get less common because we want all
implementations to get patched and clients may start requiring the fix
because this is the only way they can protect themselves.   

The ciphersuite-changes-handshake proposal has similar properties except
we expect that there are few broken servers that will barf on an unknown
ciphersuite (Situation E).  This proposal extends TLS in a non-standard
place by having the presence of a specific ciphersuite act as a side
channel to change the behavior of the TLS handshake for all current
versions of TLS.   I don't think this is something that we would want to
promote in the future, the code to handle this would be "one-off" code.

>From a functional point of view I don't see any difference between A) RI
extension with option ciphersuite signal in the case of fallback for
broken servers and B) ciphersuite-changes-handshake proposal.  

In TLS we have two standard ways of extending the functionality defined.
One is extensions and one is the version number.  Changing the version
number is not really helpful at this point because it would require all
systems to update to TLS 1.3 and its not clear that any of the
situations above would change.  Extensions are the way to extend the
spec.  Extensions are now part of the base specification and we want
implementations to process extensions correctly even if they only
support the RI fix.  

I think it comes down to whether we want to extend TLS in a standard way
for compliant implementations with a non-standard fallback behavior for
handling non-compliant implementations or extend TLS in a non-standard
way for all implementations.   The standard vs. non-standard is somewhat
nonsensical because we can make something standard with IETF consensus,
however this will have implications on implementations and future
extensions moving forward.  

IMO, given that the two approaches are functionally equivalent I would
prefer to extend things in the standard way.

---

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

At Sun, 15 Nov 2009 03:13:01 -0800,
> deal with broken implementations.  

So, thinking further on my earlier message, I think the following 
elaboration will work a bit better:

- Strict clients (those which wish to insist on RI) generate RI on
  initial handshake. As I said earlier, I don't think this is
  useful, but it works.

- Lenient clients do not generate RI on initial handshake but do
  generate it on rehandshake with TLS 1.0+ only. 
  + Moderately lenient clients can fail if the server does not
    do RI.
  + Really lenient clients can ignore the server's failure to
    do RI.

This has the following advantages:
For all non-renegotiated settings you get exactly the same interop
properties you ordinarily would. I.e., it just works. With
renegotiation, you get an extremely high interop probability even if
the server has not upgraded because compliant TLS implementations are
required to at worst ignore extensions (RFC 2246; S 7.4.1.2), and
you've already weeded out SSLv3-only implementations in the initial
handshake.

Now, there is still arguably a downgrade attack because the attacker
can simulate a completely broken SSLv3 stack and force you down to
SSLv3 in the initial handshake (they can't do it in later handshakes
because those are protected). Note, however, that since we're not 
exercising the extension logic in that handshake (though of course
the client may be exercising it for some other reason, say if it's
doing SNI), the server the attacker is simulating has to be really broken
because it's not handling version number negotiation correctly. However,
we can still use a cipher suite indicator if we think it's absolutely
necessary to allow fallback to SSLv3 here.

-Ekr

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 09:59:19 -0800

>  + Really lenient clients can ignore the server's failure to

Yes, please.  I was going to send an email asking for this, but you  
beat me at it.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Sun, 15 Nov 2009 20:13:18 +0100 (MET)

First of all, please keep in mind that server that do not
implement renegotiation have never been vulnerable in the first
place.

The only thing that those would have to add is the signaling on
the initial handshake.  They don't need to be able to exchange
finished messages and neither do they need to change their
finished message calculation.  Just recognizing the clients
signal and back-signaling "don't worry, I'm a nice server"
is all they ever need to patch.

> not, if the server is implemented correctly. 

That is an extremely huge if.

It is currently extremely unsafe to send an extension in the ClientHello,
therefore I'm extremely reluctant to add this to our client codebase,
because our apps do not have a reconnect fallback.

> policy and disallows connections to non patched servers

This policy would mean that you brick the entire installed base,
including those that have never been vulnerable.

> because this is the only way they can protect themselves.   
 
Situation E is the Killer for the TLS extension RI.

You can not seriously propose that people add reconnect fallbacks to all
their applications in order to be able to use TLS extension RI in their
clients during the transittion period and then after the transition period
ask the apps to dump that huge amounts of code they had to implement
because it is also a security problem.

With the current installed base, using TLS extension to wrap the fix
is a non-starter.

> broken servers and B) ciphersuite-changes-handshake proposal.  

If we use signaling through special ciphersuite ID, then we do not
need the TLS extension anymore.

The real problem of the TLS extension RI is the presence of the
TLS extension on the initial handshake.  If you remove the TLS extension
RI from the ClientHello of the initial handshake, then the interop
problems will go away.  Only the superfluous waste of network bandwidth
on the renegotiation remains.

> One is extensions and one is the version number.

Excuse me, the Internet user do _NOT_ want us to make bold experiments
and play around with extensions.  They want us to fix a problem in the
protocol that has been there for a very long time.

If the SSL renegotiation had been designed correctly from the beginning,
noone would have come to the idea to invent and use a SSL or TLS extension
for this.  One would have added the finished messages of the previous
handshake into the handshake message hash of renegotiation handshake.

It is simple and straightforward to apply the fix to the protocol,
it creates significantly less interop problems with the installed base
and does not waste and network bandwidth.  And we want to only use the
secure renegotiation in the future, so there is absolutely no problem
in getting that "new code path" work correctly.  I assume that my
proposal is 50 lines of code at most. 

>
> Changing the version number is not really helpful at this point
> because it would require all systems to update to TLS 1.3 and
> its not clear that any of the situations above would change.

Huh?  What are you talking about?

My proposal works just fine with SSLv3 (0x03,0x00), noone will need
to upgrade anything.  But for TLSv1.3, we should no longer support
the old renegotiation.  This is why the extension, which will
stick around for eternity, looks pretty awful, continuing nuisance
and unnecessary waste of network bandwidth.

> Extensions are the way to extend the spec.
> Extensions are now part of the base specification and we want

We do NOT NEED and extension for TLSv1.2.

We urgently need a _FIX_ for all deployed protocol versions, including
SSLv3, TLSv1.0 and TLSv1.1.

Please stop refering to the fix as an extension, it is not an extension,
and should not be described as one (and IMHO also not wrapped as one
on the network).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 15 Nov 2009 13:07:28 -0600

> deal with broken implementations.  

No, I don't think so.  The RI proposal is fine in all respects, except
that if there are old servers that are broken w.r.t. extensions and
which could get patched to implement a simple fix, then RI is possibly
too complex.  Or at least that's what I think Martin is arguing.  I'm
not sure that's the case either.

I think the RI is fine, but if it's not (see above) then we need _data_,
meaning: names of implementations and implementors that are committed to
fixing such old SW and who prefer a non-extension-based solution.

> The ciphersuite-changes-handshake proposal has similar properties except

Which proposal is that??  I proposed a fix that changes only the
Finished message verify_data computations.

> extensions moving forward.  

I agree.  I dislike the argument that Hello extensions, being the
blessed extensibility facility of TLS, is what must be used, but that
alone is not enough to ditch EKR's proposal!

> prefer to extend things in the standard way. 

EKR's proposal is being interop tested as we speak.  That gives it a
head start.  IMO I think we'll end up with that.  IMO folks who really
want an alternative will have to come up with data (see above).

Nico
--

---

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

>   + Really lenient clients can ignore the server's failure to

Aren't your so-called Lenient clients still 100% vulnerable to the attack?

What prevents their initial handshakes from being used by an attacker as
renegotiations with a vulnerable server?

---

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

On 2009-11-15 03:13 PDT, Joseph Salowey (jsalowey) wrote:
> We need to close on this issue.  

Agreed!

> is well-known, but it leaves a roll-back attack open.  

AFAIK, there is a small number of well known client products (browsers)
that do this today.  These products offer ("push") updates quite frequently.

I think it is probable that these products will alter their fall-back logic
in light of this vulnerability, so that it will not be a trivial way for
attackers to bypass the fix for the vulnerability.

> because this is the only way they can protect themselves.   

Agreed.

---

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

> renegotiations with a vulnerable server?

Not connecting to a vulnerable server would.  In the web browser  
scenario, if I know that the HTTPS servers I use for serious purposes  
are not vulnerable (i.e. don't allow renegotiation, other than  
possibly with the updated renegotiation protocol), I'm fine.

When an HTTP page points me to an HTTPS page that I haven't heard of  
before, where I wouldn't even bother to verify the certificate's  
subject name or the hostname, then I don't care at all: I don't know  
if the entity that owns the certificate is who I think is running the  
site anyway.  Maybe a "Man-in-the-Middle" style attacker is handling  
all my connections and forwarding them to the real server in TLS  
renegotiation handshakes -- so what?  The attacker could just as well  
have directed me to another domain for which they have a certificate.   
If there's no active attacker, I'm fine to the extent that it's  
possible: my traffic is at least safe from passive eavesdroppers.   
Without a lenient client, I'll actually lose something if the servers  
haven't been upgraded because I might have to fall back to an  
unencrypted connection instead.

Bodo

---

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

On 2009-11-15 14:22 PDT, Bodo Moeller wrote:
>> What prevents their initial handshakes from being used by an  
>> attacker as renegotiations with a vulnerable server?
> 

Right.  In the presence of a "white list" of known invulnerable servers,
no client protocol modifications of any kind are necessary.

> subject name or the hostname, then I don't care at all: 

Right.  That case is not interesting.

The interesting case is the server that you have heard of before, and do
use, perhaps with some frequency, but you do not know if it is vulnerable
or not.  Since you are a regular user of that server, if it is vulnerable
then the next time you use it, you may be vulnerable, too.  As a lenient
client of that server, you have no protection from the attack.

---

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

> client of that server, you have no protection from the attack.

Yes.  Using a lenient client means the responsibility to protect  
against the attack is with the server.

Bodo

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 15 Nov 2009 15:35:07 -0800

> > 
> > E. The RI proposal has an issue if the client is patched and the 
> > server does not implement the SSL 3.0 and the TLS 1.x specs 
> correctly 
> > and the client as a lenient policy which allows connection 
> to insecure servers.
> > (reconnect without extensions) to deal with broken servers.  This 
> > logic is well-known, but it leaves a roll-back attack open. 
>  This can 
> > be plugged by using the proposed ciphersuite signal only in 
> the case 
> > where extensions cause a handshake or connection failure.  The 
> > fallback cipher-suite signaling for RI to prevent rollback 
> extends TLS 
> > in an unexpected way, but this is limited only to the case where we 
> > have to deal with broken implementations.
> > 
> > Situation E is one that we expect to get less common 
> because we want 
> > all implementations to get patched and clients may start 
> requiring the fix
> You can not seriously propose that people add reconnect 
> fallbacks to all their applications in order to be able to 
> use TLS extension RI in their clients during the transittion 
> period and then after the transition period ask the apps to 
> dump that huge amounts of code they had to implement because 
> it is also a security problem.
> 
> 
> With the current installed base, using TLS extension to wrap 
> the fix is a non-starter.
> 
[Joe] Eric pointed out that if you are going to have a lenient policy
that you don't need to send the extension in the initial handshake.  

> >
> > The ciphersuite-changes-handshake proposal has similar properties 
> > except we expect that there are few broken servers that 
> will barf on 
> > an unknown ciphersuite (Situation E).  This proposal 
> extends TLS in a 
> > non-standard place by having the presence of a specific ciphersuite 
> > act as a side channel to change the behavior of the TLS 
> handshake for all current
> > From a functional point of view I don't see any difference 
> between A) 
> > RI extension with option ciphersuite signal in the case of fallback 
> > for broken servers and B) ciphersuite-changes-handshake proposal.
> 
> If we use signaling through special ciphersuite ID, then we 
> do not need the TLS extension anymore.
> 
> The real problem of the TLS extension RI is the presence of 
> the TLS extension on the initial handshake.  If you remove 
> the TLS extension RI from the ClientHello of the initial 
> handshake, then the interop problems will go away.  Only the 
> superfluous waste of network bandwidth on the renegotiation remains.
> 
[Joe] OK, right.  SO it seems that situation E with RI is not as bad as
I stated.

---

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

At Sun, 15 Nov 2009 13:14:31 -0800,
> renegotiations with a vulnerable server?

Absolutely nothing. As far as I know, the only way to avoid that is to
refuse to connect to any server that you can't verify is upgraded,
which, at least for the moment, is basically the same as saying you
can't connect with a very substantial fraction of the Internet. It
might well be possible to probe as you suggest in a subsequent
message, but I don't think there's going to be a good way inside
TLS...

-Ekr