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

Ralf Skyper Kaiser <skyper@thc.org> Fri, 06 December 2013 22:31 UTC

Return-Path: <skyper@thc.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 133261AD9AE for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 14:31:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 75XSMfdqPp6n for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 14:31:04 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 655021ADF81 for <tls@ietf.org>; Fri, 6 Dec 2013 14:31:04 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at1so2440313iec.33 for <tls@ietf.org>; Fri, 06 Dec 2013 14:31:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O26pgMPgwZqj68oDW1Lrzw4CPSVW4T/hWmTiAniokvo=; b=UMYV/ZD1exvB0Rvr7HPWuISUBX4PS127elU/nhaJYwtdPfOl6KJXIux237HxmPPYdF hyOPBPYChOnLB6hzvtE6QPcBpixjkq0t+wPrgSFhq3bfS6yiG+H6LXdT6UPExfPJ4x33 0DPDwJlYbHMdjbE4xizCdivtkdguh2n/xV/Nk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O26pgMPgwZqj68oDW1Lrzw4CPSVW4T/hWmTiAniokvo=; b=CkAHc2eKPxsGbjiMRI0ShA2XxAoKoFOrtdyUCk0rNJgFwD/3dz8fnb3IpA1y8XUaUC k9qd/5m+TuwvSZ9QuxtRxK/dC5mTPn95ZG6maT9c/uRHYjUw8pri4h198rrj8XEULwlC 7p+2cUmj8eCvPXPoplBryS67y9toZEy8DbJ7z9F3IJypfBzyAiVEEtd5NSFNh3TDmY8z Z52l5k0pSht6B1La4rqam5pt6AQzc+THPRKVj8PnEexk0A+85hJ6bvSry233OdabTT7u 9l6QoAVj5d7PnbeTzbuEd9TfrHjdg5QXShGDqDbbhJ35KlrWKK8EFAzZSoH3h8y8KMm9 UBkw==
X-Gm-Message-State: ALoCoQmifT4Ce5ZcXuiNJT/rHdcJgvVdjapY+LBtdI468UK99FO7h+lU4K+6Kopuxpp0gYBd9Tdt
MIME-Version: 1.0
X-Received: by 10.50.17.9 with SMTP id k9mr4910240igd.3.1386369060450; Fri, 06 Dec 2013 14:31:00 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Fri, 6 Dec 2013 14:31:00 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com>
Date: Fri, 6 Dec 2013 22:31:00 +0000
Message-ID: <CA+BZK2rbjcx+sT9BU5sjKsuH81N+02xdLD3CmreaGzjRn-ibdA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=089e01182a3460eb8304ece533f4
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: Fri, 06 Dec 2013 22:31:07 -0000

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> wrote:

> On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <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
> https://www.ietf.org/mailman/listinfo/tls
>