Subject: [TLS] user requirements for TLS fix

From: Chris Newman <[email-masked]>
Date: Mon, 16 Nov 2009 19:23:37 -0800

As a power user, I want two settings for my all my TLS clients ASAP:

 1. treat unpatched servers as if SSL/TLS was not being used with respect to
    security indicators in the UI; but otherwise continue with connection.

 2. Warn when contacting an unpatched server giving me the option to abort 
the transaction
    (and even better if it won't bother me for a month or so if I choose to 
continue).

I will use option 1 most of the time initially and will switch to option 2 
when the time is right (maybe a year or so?).

A non-power user is best served by option 1 for the foreseeable future, but 
this will generate support calls that some ISPs and business enclaves will 
find unacceptable.  These sites will insist on a "no change from today" 
behavior until the majority of servers are patched or enough 
customers/banks demand otherwise.  Closed-source client vendors are likely 
to make options 1 & 2 default off for that reason.  Open-source clients 
might get away with option 1 default on.

Particularly security sensitive sites will want the ability to log on the 
server and/or block at the outbound firewall clients that are not patched. 
Such sites will also require that un-patched clients work with internal 
already-patched servers for a transition period.

I would consider option 1 suitable for an IETF best _current_ practice 
document.  That would mean we expect most clients to send the RI extension 
most of the time, even if they have no plans to renegotiate later, as 
that's they only way the client can produce a correct security indicator 
for the user.  This will have issues with previously mentioned (but as yet 
unidentified) broken SSL 3 server implementations.

It is possible to produce an alternative proposal with a slightly better 
backwards compatibility profile than draft-rescorla-tls-renegotiation-00 
that meets the above user requirements.  However, there is no such proposal 
in the form of an Internet draft that has been both implemented and 
interoperability tested between implementations to the level that RI has. 
I consider time-to-market a much higher priority than backwards 
compatibility with servers that implemented SSL 3 incorrectly.  So at this 
stage I propose we immediately adopt draft-rescorla-tls-renegotiation-00 as 
a WG document (I understand this decision is the chair's discretion), get 
it revised to fix the issue Nelson identified and start IETF last call and 
WG last call in parallel.

		- Chris

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 19:48:15 -0800

I appreciate wanting to move on this, but the heated discussion over
the past few days has been over problems with the RI extension.  The
good news is that I think we've finally reached consensus on a better
alternative.  I summarized it in another message, with a slight twist
that makes it even more compatible with existing code since no
extensions are required in either direction.

Please see:

   http://www.ietf.org/mail-archive/web/tls/current/msg04393.html

I've already implemented the RI extension in my own code, so it will
be extra work for me to rip out my changes and start anew, but I do
believe this is better for the rest of the world that still has yet
to implement a fix.

Mike

Chris Newman wrote:
> 2. Warn when contacting an unpatched server giving me the option to 
> abort the transaction
>    (and even better if it won't bother me for a month or so if I choose 
> to continue).
> 
> I will use option 1 most of the time initially and will switch to option 
> 2 when the time is right (maybe a year or so?).
> 
> A non-power user is best served by option 1 for the foreseeable future, 
> but this will generate support calls that some ISPs and business 
> enclaves will find unacceptable.  These sites will insist on a "no 
> change from today" behavior until the majority of servers are patched or 
> enough customers/banks demand otherwise.  Closed-source client vendors 
> are likely to make options 1 & 2 default off for that reason.  
> Open-source clients might get away with option 1 default on.
> 
> Particularly security sensitive sites will want the ability to log on 
> the server and/or block at the outbound firewall clients that are not 
> patched. Such sites will also require that un-patched clients work with 
> internal already-patched servers for a transition period.
> 
> 
> document.  That would mean we expect most clients to send the RI 
> extension most of the time, even if they have no plans to renegotiate 
> later, as that's they only way the client can produce a correct security 
> indicator for the user.  This will have issues with previously mentioned 
> (but as yet unidentified) broken SSL 3 server implementations.
> 
> that meets the above user requirements.  However, there is no such 
> proposal in the form of an Internet draft that has been both implemented 
> and interoperability tested between implementations to the level that RI 
> has. I consider time-to-market a much higher priority than backwards 
> compatibility with servers that implemented SSL 3 incorrectly.  So at 
> this stage I propose we immediately adopt 
> draft-rescorla-tls-renegotiation-00 as a WG document (I understand this 
> decision is the chair's discretion), get it revised to fix the issue 
> Nelson identified and start IETF last call and WG last call in parallel.
> 
>         - Chris

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 17 Nov 2009 05:13:37 +0000

>   http://www.ietf.org/mail-archive/web/tls/current/msg04393.html

That article has currently had no replies. How can you say that the
group has reached concensus, on that solution or any other? It very
clearly hasn't.

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

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 21:26:43 -0800

"Consensus" was clearly the wrong word.  "Convergence" would have been
more appropriate.  I've read every word of every message and it's clear
that this has all the ingredients people are asking for:

    - is minimally invasive:  works even for SSLv3 without needing
      extensions or modifying any handshake message in any way
    - signals in both directions in the clear
    - incorporates the previous verify_data in the handshake
    - does not waste bandwidth
    - protects "lenient" clients as much as possible
    - probably others

Since you read it, care to comment?

Mike

---

From: <[email-masked]>
Date: Wed, 18 Nov 2009 14:31:31 +0100

Chris Newman wrote:

>  1. treat unpatched servers as if SSL/TLS was not being used with
> respect to security indicators in the UI; but otherwise continue
> with connection.
> 
> abort the transaction (and even better if it won't bother me for a
> month or so if I choose to continue).
> 
> I will use option 1 most of the time initially and will switch to
> option 2 when the time is right (maybe a year or so?).

This seems to be confusing "unpatched" (*) with "vulnerable".

But servers that never allowed renegotiation to begin with are not
vulnerable, and many others can just disable renegotiation (without
implementing anything else). These servers won't have any need
to patch, and will be around "unpatched" much longer than a year 
from now.

(*) I'm guessing here "unpatched" means "do not implement some kind of
signalled change to TLS protocol (either a TLS extension, magic
cipher suite, alert message, change in Finished message calculation,
or something else). It seems actually probing whether the server 
is vulnerable (i.e., supports "old style" renegotiation without 
any of the proposed fixes) isn't very reliable (or otherwise good idea).
 
Best regards,
Pasi
(not wearing any hats)

---

From: David-Sarah Hopwood <[email-masked]>
Date: Wed, 18 Nov 2009 23:30:11 +0000

> This seems to be confusing "unpatched" (*) with "vulnerable".

Since "unpatched" cannot be reliably or efficiently distinguished
from "vulnerable", then there is no choice but to treat them the same,
in respect of UI indicators or anything else.

> to patch, and will be around "unpatched" much longer than a year 

All servers, regardless of their vulnerability, will have to patch if
they are to remain interoperable with strict clients.

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 08:35:49 +0100

> they are to remain interoperable with strict clients.

There are several ways how this system could go. Some possibilities:

1) someone ships a "strict client" (that complains to user when
detecting an unpatched server") --> users get annoyed --> users
complain to server owners --> whole world upgrades their servers 
(even those that never were vulnerable)

2) someone ships a "strict client" --> users get annoyed --> users
complain to client vendor --> strict mode is turned off in the client

3) someone ships a "strict client" --> users get annoyed --> users
complain to server owners --> server owners (correctly) say they're
secure already --> users complain to client vendor --> strict mode 
is turned off

(And several variations of these.)

My personal opinion is that #1 is the *least* likely course of events
(and #2/#3 -- or some similar situation where the end result is nobody
using strict mode -- is more likely), but this opinion is clearly
based on "gut feeling", not hard facts, so I realize others may
reasonably arrive at a different conclusion.

Best regards,
Pasi
(not wearing any hats)

---

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

> (And several variations of these.)

Some clients *will* be strict, even if those are not web browsers.
I suppose it is possible that the web will take a long time to catch
up to requiring security against this attack; it always does. But it
will eventually catch up, even if it takes as long as it did to
disable SSLv2 in most clients.