Subject: Re: [TLS] draft-rescorla-tls-renegotiate.txt

From: Martin Rex <[email-masked]>
Date: Sat, 7 Nov 2009 00:53:46 +0100 (MET)

Nicolas Williams wrote:
> 
> Stop using SSLv3.  Its end has arrived.

I was actually looking for an answer from engineering,
not for one from sales.  :-|

We might need to ask a few hundred million users to enable TLS 1.0
on their MSIE browsers running on Windows XP.

And you really should not underestimate the amount of software
where it needs much more that a registry key to obtain TLS support.

The answer might not be as simple as saying "drop SSLv3 support".

Nasko Oskov wrote:
> 
> Dare I say block renegotiations in SSLv3? Most implementations
> have had TLS1.0 support for a long time, so compatibility
> impact should be fairly low.

That misses the point somewhat.  There are several aspects
that need to be addressed.

*I* do not have a problem with requiring servers that want to continue
using renegotiation to upgrade to at least TLSv1.0.  I think that
is doable.

But what are we going to require from Servers that use the delayed
authentication through renegotiation, and want to continue using it
when SSLv3 clients connect (either stuck at or configured for SSLv3 only)?

I think we ought to require them to refuse traditional renegotiation
in the future (what should they send back to v3.0 clients trying)?

They could send a CertificateRequest to v3 clients in the initial
full handshake instead (causing a slightly different "user experience"
to TLSv1.x clients with delayed authentication).  I would like to
require them to do that (if they support client-cert authentication)
but I do not think we can do that, and I have no idea how difficult
that would be for the various servers to implement.

But all that doesn't give the clients the possibility to protect
themselves from the MITM attack (that what is described in
the client considerations of Eric's proposal).

It leaves an extremely bad taste if we push people with software
that is not vulnerable in order to protect against a vulerability
of a number of broken servers with whom they're not affiliated.

What would you think if suddenly someone in your street would
get himself a very dangerous, huge and badly tempered dog and
he would let him outside regularly -- with no fence and no leash
and the other 12 neighbours in the street would have to put up
fences around their property to protect from that dog.

IMHO, the guy with the dog should be required to either
build a fence around his property, put the dog on a leash or chain
or get rid of it.

If we agree on a fix to this problem in TLS, and the deployment
results in interoperability problems that can _not_ be easily fixed
(and it is naive to assume there will not be any, the installed
 base is so awfully large), then the wording of our specification
and requirements may make a difference on who will have to change
what based on contractual obligations. (IANAL though)

And personally, I think that neither "Your SSLv3 client is to old"
nor "get the update for your TLSv1.0 client" is a justified
position, because in most cases it is purely a problem of the server.

There also is a much higher likelyhood of servers being under
maintenance (support contract), than clients.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Nov 2009 17:59:38 -0600

> not for one from sales.  :-|

:/

Right, the real choice is: stop using re-negotiation without the fix
and/or stop using TLS without the fix (which means stop using SSLv3).

The first choice leaves clients without the fix vulnerable when they
talk to servers that don't have the fix and do accept re-negotiation.
That's pretty bad (surely many servers won't get the short-term fix).

The second choice renders a large portion of the installed base
non-interoperable.  That's... much worse.

I don't know how addicted we are to re-negotiation and SSLv3, so I can't
tell you which choice should win in the short-term, but then, I think
turning off re-negotiation may well prove easier than we may have
thought (see my reply to Marsh just now).  In the longer term though, we
should deploy the fix and SSLv3 clients should go away.

Nico
--

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 06 Nov 2009 16:16:14 -0800

> in the future (what should they send back to v3.0 clients trying)?

Here is an alternative that should have the same user experience and not
be MITM vulnerable, not even with SSL 3.0 clients:

   Replace renegotiation with redirection.

Set up a second https server (process) on the same physical server, e.g
a different port on the same IP address.  The new server always requests
client authentication on the initial handshake, not in a renegotiation.

All the assets that formerly lived in the original server and formerly
required renegotiation for client authentication are moved to the second
server on the new port.  In their place on the original server in placed
something that redirects the user to the asset's new location on the new
server.

The user visits the first server, and is redirected to the second server,
whereupon he is asked for his client certificate.  This all seems to him
the same as before, but no renegotiation has occurred.

Since the two servers reside on the same IP address and same box, they
can share the same certificate and private key, so there is no additional
cost for additional certificates (sorry, CAs).

The only area where this MAY not work that occurs to me is POST.  I seem
to recall that some (most? all?) browsers will not re-POST data if they
get a redirect after doing the initial POST.  So, the two servers might
have to collude (:-), with the first server saving the POST data, and
setting a cookie, or putting a unique string into the redirected URL that
the second server could use to find the data saved by the first server,
after the user authenticates to it. (Maybe somebody come up with a better
alternative to that.)

---

From: Martin Rex <[email-masked]>
Date: Sat, 7 Nov 2009 02:00:45 +0100 (MET)

> client authentication on the initial handshake, not in a renegotiation.

That is actually what our clients usually have to do since the
OEM SSL/TLS library we provide does not support renegotiation on
the server side (its also not in our apps software layers).

There is one itch I have with this:
A number of Web Proxies (like the one of our company) does not
permit HTTP CONNECT to ports other than 443.

Should we ask for an additional port to be officially allocated
to http-over-ssl-with-client-cert so that we can get this past
our security policy (not joking)?

-Martin

---

From: Chris Newman <[email-masked]>
Date: Wed, 11 Nov 2009 15:59:26 -0800

--On November 7, 2009 2:00:45 +0100 Martin Rex <[email-masked]> wrote:
> to http-over-ssl-with-client-cert

This is a good idea.

HTTP authentication is particularly badly designed, but we can't really fix 
it so we have to live with it.  Having a separate port for 
HTTP-with-client-cert-mandatory where the server can "just know" that 
client certs will be present in the initial handshake and will never be 
renegotiated, and the client can "just know" it has to prompt the user for 
client cert selection removes some of the need for all the security 
"fudging" HTTP does and thus is an overall security improvement, IMHO.

I would not want other protocols to copy this mess, however -- application 
protocols should have a clean and simple state transition between "not 
authenticated" and "authenticated" state.  POP, IMAP, XMPP, LDAP, BEEP and 
even Telnet did this better than HTTP.

		- Chris