Re: [TLS] An SCSV to stop TLS fallback.

["Yngve N. Pettersen" <[e-mail]>]

On Thu, 05 Dec 2013 00:05:43 +0100, Marsh Ray <[e-mail]> wrote:

> What percentage of these client fallback operations that actual users  
> browsers are doing in the real world are being triggered for reasons  
> *other* than actual server implementation bugs? I imagine this could be  
> a difficult thing to measure. But I can also imagine the obvious client  
> heuristics (if it fails, try again) could easily be triggered by a busy  
> server or simple packet loss. Couldn't this represent a full 1% of  
> connections, especially now that so many users are on mobile devices?

It is definitely a possibility.

One part of Opera's (v12 and before) logic regarding fallbacks was to fall  
back if the connection took too long to establish after the handshake had  
started, since some problematic servers would never respond if they did  
not like the handshake. IIRC the trigger time was 6 or 10 seconds.

> So if a fallback situation was a slow-loading lousy page experience  
> before, what's it going to be after legitimate servers implement this  
> logic? Will servers actively *refuse* legitimate client's retry  
> connections? If so, isn't this just taking an intermittent slow-failure  
> situation and converting it to an even slower but guaranteed interop  
> failure? If not, what good will downgrade protection logic be?
>
> TLS 1.2 was designed to mitigate some serious potential attacks. BEAST  
> demonstrated these attack vectors could be practical.
>
> We need to recognize ad-hoc client fallback heuristic for what it is: a  
> security vulnerability.
>
> Therefore, clients MUST NOT auto-downgrade.

The main point of contention is how to accomplish this without "breaking  
the web" and how to do this in a fashion that improves security quickly.

The SCSV proposal very likely will not "break the web", but my objection  
is that it will require updates to all the servers, and not just the  
clients, and thus take too long to deploy (case in point: 4 years after  
the Renego problem was discovered, 20% of servers are still not patched).  
Given that. 14 years after TLS 1.0 was released, about 1% of servers still  
only support SSL v3. I do not have high hopes of having SCSVs fully  
deployed in 15 years (unless client vendors decide to, or have to, "break  
the web").

My suggestion have been to update the clients to refuse to use fallback  
when connecting to servers that implement the Renego patch. This have the  
benefit of using a proxy for correct version negotiation, which is already  
deployed on a majority of servers. The drawback of my proposal is that the  
proxy indication is not perfect; there is a small fraction of patched  
servers that are version and/or extension intolerant, and there is a much  
larger fraction of servers that are version intolerant for whatever  
version bytes TLS 1.3+ will use. Some will call the first group as  
"breaking the web", while most will probably agree that the second can  
definitely be called "breaking the web".

The question is, if client vendors agree to "bull through" and refuse to  
fall back, will the server vendors and web site operators fix their  
implementations, and if so, how quickly? The best option in such a  
scenario would probably be a coordinated same-day release  (alternatively  
flipping a flag) of updated clients, particularly browsers, so that web  
sites cannot use the "switch browser" "advice" for fixing the "browser  
bug". (Flipping a flag might be the better option, since this will allow  
the updated browsers to gain a sufficiently large marketshare before  
changing the behavior)

What to do comes down to the answers to a few questions:

  - How much website breakage will be tolerated for a fix? (keep in mind  
that the fix will almost certainly require the client or server to abort a  
connection that cannot be started without a fallback, if not, what's the  
use?)
  - How secure do the vendors, website administrators and users want the  
web to be?
  - How quickly is it desirable to obtain that level of security?

The answers to each of these affect the answer to the others, so the trick  
will be to find a useful compromise that does not compromise security.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/