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

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 07 December 2013 10:40 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 9DFE21AE2BE for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 02:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 G1U8Oxg_ww6E for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 02:40:56 -0800 (PST)
Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD7E1AE2BC for <tls@ietf.org>; Sat, 7 Dec 2013 02:40:56 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id d17so700450eek.39 for <tls@ietf.org>; Sat, 07 Dec 2013 02:40:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VXCf4ddiZ/7BPOE2g4a3tIMbZYuWV8idP1e1s/9XhoE=; b=zG1dr2nuODqvNVcm1+ccHq5XRBoDzoybuJucKqYISB5rGWYyShd/p8cAr38WwJJRdi fSdvWONMHD2qYcVcInv5ePBL93shjq0bM8gOvbvyVJV2sCXJK4aUnfD/6llhftiPIG+3 hQyhI47APpXTFr+2C2MSjnuQT2oW15uXhZoPBMQDKY3X5x38gwlza28cjBNxpg7iVpuJ ecU59qYwlyqq0eteLc6c7Z0go3zCi5ifZvakXmfp0tksKywHQqcmCKrniUkKdiJwM9y7 t/ZR7cJmQuaILcR0JaIi3Cglzm87NOfydgQbiB+yzbvgeXdB4yM38jNlUeAaNxbZYVri WTow==
X-Received: by 10.14.109.5 with SMTP id r5mr41956eeg.110.1386412851974; Sat, 07 Dec 2013 02:40:51 -0800 (PST)
Received: from [10.0.0.2] ([109.65.142.155]) by mx.google.com with ESMTPSA id m1sm5173339eeg.0.2013.12.07.02.40.50 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:40:51 -0800 (PST)
Message-ID: <52A2FB32.30004@gmail.com>
Date: Sat, 07 Dec 2013 12:40:50 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com> <CA+BZK2rbjcx+sT9BU5sjKsuH81N+02xdLD3CmreaGzjRn-ibdA@mail.gmail.com>
In-Reply-To: <CA+BZK2rbjcx+sT9BU5sjKsuH81N+02xdLD3CmreaGzjRn-ibdA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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: Sat, 07 Dec 2013 10:40:58 -0000

Hi Ralf,

I like the idea of pinning the version number, but I don't think it will 
work well in clusters without significant tinkering (i.e., protocol 
changes): the client connects to cluster member A which has just 
upgraded to TLS 1.3 and immediately pins that server to 1.3. Now it 
connects to another cluster member which is still on TLS 1.2, and the 
connection is reset.

I don't understand how you could pin "ECDHE" - you would need to define 
whether DHE is better or worse than ECDHE, and I don't think we want to 
make that judgment call.

Thanks,
	Yaron

On 12/07/2013 12:31 AM, Ralf Skyper Kaiser wrote:
> Hi,
>
> the draft only concerns HTTPS (no other client side implementation
> attempts a reconnect when it receives
> a RST on  TLS 1.x [which is bad to start with but apparently necessary]).
>
> A solution that solves some of the mentioned problems without any
> protocol change is
> to pin the TLS version the same way as certificates are pinned. And
> while pinning the TLS
> version it should also be considered to pin the cipher suite ("Use this
> cipher suite or
> a better one").
>
> After first connect the client will not allow any lesser security (TLS
> 1.3, ECDHE, ..) than the one
> used on last connect.
>
> regards,
>
> ralf
>
>
> On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith <brian@briansmith.org
> <mailto:brian@briansmith.org>> wrote:
>
>     On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <agl@google.com
>     <mailto:agl@google.com>> wrote:
>      >   In the event that a client is making a fallback connection, it
>      > includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
>      > current server which sees this cipher suite in a ClientHello SHOULD
>      > return a fatal alert, inappropriate_fallback (86) and abort the
>      > connection.
>
>     Adam, I think what you propose makes sense. However, I think it might
>     not be ideal if there are any circumstances where the browser could
>     accidentally fall back to a lower version--e.g. falling back after a
>     timeout or falling back in response to the connection being reset.
>     AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
>     from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
>     be some false positives here. In addition to potentially reducing the
>     security of the connection, these fallback connections add a lot of
>     latency. If we attempt a fallback connection in response to a
>     connection reset, and we receive an inappropriate_fallback alert, then
>     we'd have to make yet *another* connection without the fallback. All
>     other things being equal, it would be better if the server could
>     respond respond exactly as it would with a TLS 1.2 ClientHello,
>     without downgrading the cipher suite or any other feature, more like
>     what Martin Rex suggested.
>
>     However, I don't think it is realistic to backport features all the
>     way to SSL 3.0. The information in the TLS extensions is too
>     important, and trying to define good defaults for missing extensions
>     that make sense long-term seems like it will just bind our hands too
>     much in the future.
>
>     So, we should could consider backporting TLS 1.2 cipher suites to TLS
>     1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
>     for for SSL 3.0 handshakes only.
>
>     Whether this complication is justified depends on how frequently we
>     receive false-positive connection resets (and anything else that can
>     be a false positive) and how much we care about optimizing performance
>     for that case.
>
>     Cheers,
>     Brian
>     --
>     Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>