Re: [TLS] An SCSV to stop TLS fallback.
Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 07 December 2013 15:02 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 1EB091AE363 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 07:02:41 -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 IqcySeJ0MDqT for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 07:02:38 -0800 (PST)
Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9DE1ADFD5 for <tls@ietf.org>; Sat, 7 Dec 2013 07:02:38 -0800 (PST)
Received: by mail-ee0-f54.google.com with SMTP id e51so785424eek.13 for <tls@ietf.org>; Sat, 07 Dec 2013 07:02:34 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5DOCTKjy0UaZyZ6JCHEImUNoVuX1wqe9yaEhGa6WHQk=; b=MiUaocnzS0dotNgtGBkXc3wf9lKvbcd4yzHjl9Mp8fRwc3YoQchixDTuUw+ezoD4TX K2uIEM1+odq7WWhO/CvhEh1vo2EKM9ULL3EvB3cFavwdHubwVEVY08MhfWHrgaF35xg4 RWMTxjXvnx0sl0xMC8BooLkUn8NMPlCzQ+7Wd3Uw0/WNy0oG1Ri/JL8cW9b9XfZQPFrh 19j2p/tI+Qht2eCLkGV3n/7iy25iJ1HvYMP5UleiMJAMwqH6NoftKygO1rkKg4KOx0rw hVRrG2HTY4n/n8D9gOKhx/7lhKQyD0uin+/i7TdwYzE6K3TvB/1GZY7gBGdXIIxWbpAx TkUQ==
X-Received: by 10.15.61.134 with SMTP id i6mr6428018eex.48.1386428553945; Sat, 07 Dec 2013 07:02:33 -0800 (PST)
Received: from [10.0.0.2] ([109.65.142.155]) by mx.google.com with ESMTPSA id h3sm7203412eem.15.2013.12.07.07.02.32 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 07:02:33 -0800 (PST)
Message-ID: <52A33888.80307@gmail.com>
Date: Sat, 07 Dec 2013 17:02:32 +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: Ralf Skyper Kaiser <skyper@thc.org>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com> <CA+BZK2rbjcx+sT9BU5sjKsuH81N+02xdLD3CmreaGzjRn-ibdA@mail.gmail.com> <52A2FB32.30004@gmail.com> <CA+BZK2qm75eqW9ZmvEozM_9R2xYJMmov8dyn4qz=ppJ84grrZw@mail.gmail.com>
In-Reply-To: <CA+BZK2qm75eqW9ZmvEozM_9R2xYJMmov8dyn4qz=ppJ84grrZw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
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 15:02:41 -0000
Hi Ralf, No, AFAIU the problem does not exist for cert pinning, because there is protocol involved. Specifically, the server sends out HTTP headers to indicate the pinning and its lifetime. So (for example) you can start by changing the certs on all cluster members and only afterwards enable pinning on all of them. Re: cipher-suites, if I'm using ECDHE it doesn't mean that I want future DHE connections to fail. It is absolutely legitimate to change t setting he server's software for some reason, and to thereby also change the list of supported ciphersuites. I don't think we can ever reach consensus on weak vs. strong cipher-suites on this mailing list, and such consensus would be needed to standardize such a solution. Thanks, Yaron On 12/07/2013 04:05 PM, Ralf Skyper Kaiser wrote: > Hi Yaron, > > TLS Version Pinning: > I do not have a solution for the cluster situation but I assume that the > same problem exists for pinning of the certificate. It should be solved > the same way. > > I think this would solve the fallback issue in an elegant way with a > feature that is anyway already coming to the browsers and without > protocol modifications. > > CIPHER-SUITE Pinning: > We are already making the judgment call which ciphers are NULL, WEAK and > STRONG. If I use 'STRONG' on my first connect I would not like to be > downgraded to WEAK even that in general I would like to have weak > enabled in my browser for other websites. > > > regards, > > ralf > > > > On Sat, Dec 7, 2013 at 10:40 AM, Yaron Sheffer <yaronf.ietf@gmail.com > <mailto:yaronf.ietf@gmail.com>> wrote: > > 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> > <mailto: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> > <mailto: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> <mailto:TLS@ietf.org > <mailto:TLS@ietf.org>> > https://www.ietf.org/mailman/__listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > > > > > > _________________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/__listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > > _________________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/__listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > >
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Andy Wilson
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Trevor Perrin
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Trevor Perrin
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Brian Smith
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Jack Lloyd
- Re: [TLS] An SCSV to stop TLS fallback. Manger, James H
- Re: [TLS] An SCSV to stop TLS fallback. Wan-Teh Chang
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Wan-Teh Chang
- Re: [TLS] An SCSV to stop TLS fallback. Manuel Pégourié-Gonnard
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Marsh Ray
- Re: [TLS] An SCSV to stop TLS fallback. Douglas Stebila
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. James Cloos
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. Manuel Pégourié-Gonnard
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Marsh Ray
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Daniel Kahn Gillmor
- Re: [TLS] An SCSV to stop TLS fallback. Brian Smith
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Yaron Sheffer
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Yaron Sheffer
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Manuel Pégourié-Gonnard
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller