Re: [TLS] Downgrade SCSV info

Bodo Moeller <bmoeller@acm.org> Thu, 13 November 2014 08:47 UTC

Return-Path: <bmoeller@acm.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DBF1A6FA6 for <tls@ietfa.amsl.com>; Thu, 13 Nov 2014 00:47:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.262
X-Spam-Level:
X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFtOYKjnDEdr for <tls@ietfa.amsl.com>; Thu, 13 Nov 2014 00:47:29 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7AC1A2130 for <tls@ietf.org>; Thu, 13 Nov 2014 00:47:29 -0800 (PST)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0M9Gk2-1Xhfay3TJu-00Cgtp; Thu, 13 Nov 2014 09:47:27 +0100
Received: by mail-ob0-f182.google.com with SMTP id nt9so11381146obb.41 for <tls@ietf.org>; Thu, 13 Nov 2014 00:47:24 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.174.16 with SMTP id bo16mr664932oec.55.1415868444618; Thu, 13 Nov 2014 00:47:24 -0800 (PST)
Received: by 10.60.32.42 with HTTP; Thu, 13 Nov 2014 00:47:24 -0800 (PST)
In-Reply-To: <d51dcf00811740edb16aade02a5d8fe5@CY1PR0301MB0892.namprd03.prod.outlook.com>
References: <d51dcf00811740edb16aade02a5d8fe5@CY1PR0301MB0892.namprd03.prod.outlook.com>
Date: Thu, 13 Nov 2014 09:47:24 +0100
Message-ID: <CADMpkcJcrdVJ7NN5H80NB6tcg1tB8K=cewH=A1Xx3-p_=nnsjA@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e011838ecb0b6bb0507b98f03"
X-Provags-ID: V02:K0:GdAH003u34OQ5GQ2EMaPBhOL8zOeysvU7IBV3J5vKUa kDvoJaLnsk9XQNk/H08dtVPBCXyUeXf8lgESIsdHddr86L27Dj iVhp50izwmLCmsjQAv4ublWXStRqk5ttFOcQaDGRY/pssUbOaO 9KKCavOUxV8lGeHbNcAQGPJAYniCOT5Fwa2sX3LeiL0EDoDdqE J/5bBqf/QUJYdTBvZF9dbFcIDSJxgx7yQt9s6CrsJKkNFaV8rc YLj8uGyQO5Pq3fpamsG3IFzi3+yDvXFbC2gFMw9JpLc13++XNG IACAxIN3xogyVpv2Ef9IJk4s4UILwt+1sAAbd52YNocOmlG7D4 YiFdjQq8BiKPtQbAntCr2xhCT9RztgXl3077PFiyB1HfN5GU/f W6yL/5Skga2nR6GVMGLao0uuj2KXh3Nfaqy8LGhJ6PfIGxUxQ3 9ZMG9
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GLi6EdH3mzfGE__1H1DNUcJe0WY
Subject: Re: [TLS] Downgrade SCSV info
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Nov 2014 08:47:31 -0000

Rob Trace <Rob.Trace@microsoft.com>:

 > Right, although it couldn't hurt for the client to try TLS 1.1 next in
> case
>
> > it sees an inappropriate_fallback alert. (Then in the end you have
>
> > essentially the same outcome as if trying the protocols in decreasing
> order,
>
> > in the presence of an active attacker forcing you to downgrade.)
>


> When we looked at the fallback to HTTP 1.1, it was just as Martin stated
> and there were almost 0 times when the connection completed over TLS 1.1.
> The 1.1 fallback was a lot of wasted roundtrips and did not provide any
> value.
>
>
>
> I am not sure what a wasted fallback to HTTP 1.1 would provide with SCSV,
> in that the TLS 1.0 fallback would still result in the
> inappropriate_fallback before we send any data.
>

I do understand the reasoning, although I don't think that this is a good
tradeoff.

- There are servers that are TLS 1.2 intolerant but do tolerate TLS 1.1, so
in that case the fallback to TLS 1.1 does have a chance to complete the
handshake without wasting any round trips (even if the negotiated protocol
may still be TLS 1.0).

- A handshake failure in the initial TLS 1.2 attempt may be due to network
problems rather than incompatibility or an attack. Now assume that the
server does not support TLS_FALLBACK_SCSV. In that case, if you fall back
to TLS 1.1 first (rather than straight to TLS 1.0), you'll end up using the
better protocol (TLS 1.1 instead of TLS 1.0).

I'd rather incur additional latency with servers that are TLS 1.1
intolerant than risk falling back to an unnecessarily bad protocol version.
 (I said that before, about SSL 3.0.  <Cue dramatic music>)

Anyway, if you *do* fall back from a TLS 1.2 Client Hello to a TLS 1.0
Client Hello with TLS_FALLBACK_SCSV, as I said above it might be a good
idea to do the missing TLS 1.1 Client Hello (with TLS_FALLBACK_SCSV) later
in the sequence, if you see an inappropriate_fallback alert with TLS 1.0.
This doesn't address known interoperability issues with particular servers,
but there *could* be servers that are TLS 1.2 intolerant but do support TLS
1.1 (take any decent TLS implementation and add a wacky load balancer in
front of it). This sequence still feels wrong (you really, really should
try TLS 1.1 before TLS 1.0), but it may improve interoperability further.

Bodo