Subject: [TLS] Third Option?

From: Ravi Ganesan <[email-masked]>
Date: Wed, 16 Dec 2009 14:17:06 -0800

> >>>>  As a protocol climbs the IETF standards-track maturity ladder, we
> >>>>  sometimes drop features.  I would rather see renegotiation dropped
> >>>>  from TLS than see this complexity added to TLS protocol.
> >>>
>
> And, as Marsh has said on other threads, to remove a widely used feature is
> tantamount to forking the protocol.
>
>  -Steve
>
>
A third option is to leave renegotiation in, but create an advisory that
explains the semantics; namely, it is indeed a RE negotiation, and SSL/TLS
itself is starting from scratch and not making any assumptions about what
went before and what came after. A higher layer protocol that chooses to mix
and match traffic is making assumptions about guarantees from the SSL/TLS
layer that are certainly not "explicitly" being made anywhere.

This is not because I think renegotiation should continue to work the way it
should; in fact I believe the attack discovered was valuable, and changes
discussed on this thread over the last several weeks are valuable and SHOULD
be added in --- just that they should be added in to TLS 1.3 and the
upgrades should happen in the natural order of things. Those immediately
impacted (especially those doing the no-client-auth renego client-auth
sequence) should fix at app layer.

I am just applying my own gut sense of Occam's Razor on  the
"harm caused by not fixing until TLS 1.3"
 versus
"harm caused by forcing lots and lots of clients and servers that do not
need it"
into a significant change. As someone who wore an "operations pager" for too
many years, I do not believe in "insignificant" changes. If a developer as
much as LOOKS at a disk containing operational code, they will find a way to
break it which will not be discovered until much later....

Finally, regardless of where the committee ends up, I believe the
recommendation's value in the eyes of those who have to make decisions on
"to patch now or to wait until I need to upgrade anyway" if it contains
advice on this topic. Anyone reading about this attack from the media will
have absolutely no clue as to impact.

Anyone who reads the  the first documents that came out on this issue (
http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html)
would be left with very different perceptions of the magnitude of the
impact. This is not unnatural in such matters; great minds usually think
differently...., but after all this discussion perhaps a blurb in the draft
with advice on who should immediately patch might be useful.

Ravi, www.findravi.com

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Dec 2009 16:43:01 -0600

Ravi Ganesan wrote:
> explains the semantics;

What do you (as a vendor) tell your customers when they know they are
vulnerable and call you for a fix?

> namely, it is indeed a RE negotiation, and
> SSL/TLS itself is starting from scratch and not making any assumptions
> about what went before and what came after. A higher layer protocol that
> chooses to mix and match traffic is making assumptions about guarantees
> from the SSL/TLS layer that are certainly not "explicitly" being made
> anywhere.

Netscape's use of renegotiation of from the beginning strongly implies
they believed the guarantees were present when they added it to the
protocol.

There are still ambiguities which indicate an internal inconsistency in
the spec. For example, the spec requires that application data be
allowed to interleave with the renegotiation handshake messages. There
are multiple points during the handshake at which the identity may be
considered to have changed with various degrees of authentication.

The users on this list with the high-bandwidth links to Jupiter (who
were they again?) are quite attached to this feature.

> [...] Anyone reading about this attack from the
> media will have absolutely no clue as to impact.
> 
> Anyone who reads the  the first documents that came out on this issue
> (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and
> differently...., but after all this discussion perhaps a blurb in the
> draft with advice on who should immediately patch might be useful.

In short, everyone* needs to patch and disable compatible/insecure mode
as soon as is practical.

*Except those who can prove that their endpoint cannot renegotiate and
will never be willing to talk to a server that can possibly renegotiate.
Or is a protocol that perfectly discards all state on every handshake.
This is only possible with direct code inspection and protocol analysis,
and in practice experts have been repeatedly surprised by what attacks
turns out to be possible.

Someone may reply and say "Oh this particular situation doesn't need to
patch" but again, it will likely be because some systems accidentally
fall into a few narrow categories.

- Marsh

---

From: Ravi Ganesan <[email-masked]>
Date: Wed, 16 Dec 2009 15:36:34 -0800

> vulnerable and call you for a fix?
Have TLS 1.3 code ready and tell them to upgrade to it.  Asking customers to
move to newer release in order to fix security problems is something the
market understands. (did not say 'likes').

However, if you are correct in your impact analysis in your original paper,
then an emergency patch is the appropriate response. I am not sure I know
enough to agree with your impact analysis, but either way, good job done by
your team and Martin on this discovery -- it will make TLS 1.3 better.

One stat that might allow us  to ascertain immediate impact: If I am a web
site who strictly ONLY uses server side SSL (with client auth being handled
by passwords, etc.),  And, I have ability to turn of renego. Will that do
the trick? If so what portion of SSL users fall into this use-case?

-- 
Ravi Ganesan
[email-masked]
www.findravi.com

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 17 Dec 2009 03:25:24 +0000

> will never be willing to talk to a server that can possibly renegotiate.

No, even those.

If any server does not patch, it will soon fail to be interoperable with
clients that require patched servers.

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

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Dec 2009 23:13:11 -0600

> clients that require patched servers.

Good point. But they would not be insecure, just non-interoperable.
Which is probably better than being insecure in the long run.

So every interoperable system has just has to patch, which is basically
all of them.

It's simply not practical to offer guidelines for who doesn't need to patch.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Dec 2009 08:58:15 +0200

On Dec 17, 2009, at 1:36 AM, Ravi Ganesan wrote:

On Wed, Dec 16, 2009 at 2:43 PM, Marsh Ray <[email-masked]<mailto:[email-masked]>> wrote:

Have TLS 1.3 code ready and tell them to upgrade to it.  Asking customers to move to newer release in order to fix security problems is something the market understands. (did not say 'likes').

Except that the browsers they have don't support TLS 1.3 yet. If the TLS 1.3 spec came out today, it would be years (8? 10?) before you can assume that everyone has a supporting browser.

However, if you are correct in your impact analysis in your original paper, then an emergency patch is the appropriate response. I am not sure I know enough to agree with your impact analysis, but either way, good job done by your team and Martin on this discovery -- it will make TLS 1.3 better.

One stat that might allow us  to ascertain immediate impact: If I am a web site who strictly ONLY uses server side SSL (with client auth being handled by passwords, etc.),  And, I have ability to turn of renego. Will that do the trick? If so what portion of SSL users fall into this use-case?

Yes. Disabling renegotiation on the server side solves the problem, and probably over 95% of users fall into this use case.  However, even for them, there are two problems with this solution:
 - until very recently there was no "disable renegotiation" switch on the various servers.  OpenSSL added this to 0.9.8l just last month. Upgrading to OpenSSL 0.9.8l means getting all the code changes between the release you're using and the new OpenSSL version. This might cause you other problems.
- There's no signaling that renegotiations are disabled. The browser cannot show me that I'm talking to a secured server.

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 17:01:40 +0100 (MET)

Yoav Nir wrote:
> Have TLS 1.3 code ready and tell them to upgrade to it.  Asking customers
> to move to newer release in order to fix security problems is something
> the market understands. (did not say 'likes').

I haven't seen a market that understand this.
Vendors have been shipping very annoying auto-update functionality
in order to get at least a part of the installed base to upgrade.

Outside of the commodity market, you may get to see some customer's
lawyers if you suggest "moving to a newer release" instead of providing
a patch to defects in your products.

> - There's no signaling that renegotiations are disabled.
>   The browser cannot show me that I'm talking to a secured server.

Yes, I feel so much safer when I know that I'm talking to an TLS-updated
rogue server.  The difference this update will make is much smaller
as some try to make you believe.  It is definitely not like you
are competely and hopelessly insecure without it, and
top-notch invincible as soon as you deploy it.

The endpoint identifications used by application protocols on top of
TLS contains plenty of weaknesses itself.  So it's not like you
should stop worrying.  It's just that your focus shifts and you
have to worry more about other things now, some of which may me
much harder to fix.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Dec 2009 20:06:17 +0100

Just to clarify my own position on this.

I believe we should fix this issue and I would personally favor the mrex
draft approach as it provides better security properties, is cleaner and
more generic.

However, if the consensus for some reason would be to NOT provide a fix,
then I think it would be better to just clarify the security properties of
current renegotiation rather than attempting to ban it.

/Stefan

On 09-12-17 5:01 PM, "Martin Rex" <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 17 Dec 2009 12:42:45 -0800

> clients that require patched servers.

And if the patches to the server include patches that are not desired
by the entity running the server?  The only option then is to divert
incredible amounts of resources (especially to a tiny operation --
remember, small business accounts for 80% of economic growth in the
United States, according to the Small Business Administration) to
changing to a different server, with different code and interface
requirements.

-Kyle H

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 18 Dec 2009 02:22:58 +0000

Kyle Hamilton wrote:
> by the entity running the server?

Then they have at least five options:
 - be non-interoperable;
 - try to get a backport of just the renegotiation patch from the server
   implementors;
 - do such a backport, or commission one, if the server code is available;
 - patch anyway;
 - switch to a different server.