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

Wan-Teh Chang <wtc@google.com> Wed, 04 December 2013 02:28 UTC

Return-Path: <wtc@google.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 0FF2F1AE018 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 18:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level:
X-Spam-Status: No, score=-1.38 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, RP_MATCHES_RCVD=-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 Z1pfMZSME-uV for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 18:28:32 -0800 (PST)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6605B1ADF96 for <tls@ietf.org>; Tue, 3 Dec 2013 18:28:32 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id hz11so10610589vcb.17 for <tls@ietf.org>; Tue, 03 Dec 2013 18:28:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aMEi1XYGDHZhHBW9EigTLqabmPen+8cR7E/NoTvhsMs=; b=XQl89SElDnTEaH0U3tibipEvTMeW0m8nXvdg2wcunCPWp/lLmVXsDqpgW6oS9iTEQX 3b3EWkRB/u3+fACIy6I6yUuAsg4+PnXmD2NufhJrDytzvT99dGbPskWXywYw6/hr/yyG dWHv3p0KdknzUmGCBT+R3EFf4pX8wheUuV2PtyM3sRPS/Szj7gSpdPlhJ1AlF04zek5U 8BMZ/OCMdus9gs0hZyPlRFJuskR8IowybpBCfjIbJUMQJencJUWQXC5KmtBF4Bp1owHl 7XjdVyC5PmObrs3CT3WBChQVMpop/9Nt+cAfiwJW56HBRW6Xb0X2fIvnj4L8KNBs1Xs8 F8Ng==
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=aMEi1XYGDHZhHBW9EigTLqabmPen+8cR7E/NoTvhsMs=; b=Xz5iYaLhMvM2Mcb+BPoEPUpwxJ8B9SDQewuMAxiBQ25OZapz3wsHTlcmrc9mAnZy5m pJIxvGakWS2KvsdiSpDVX1fbBbWOJwclCpoI96M0jyt5TX6l8EBLeLIVHnf6zNZEZRAx oDyJ4mgGUrd5TPCbfM4xW7CEnubFZZAgGKijkBkfuu4f1EmZERSusFwTHHcUmAZXycHD e10nI6lRn4lMNJCR8or2+W5QkYiZ1svaKlwXs1jaXGzxA2LnEFxX59ciAfKGx26D70wX AaferzYiLOQ/z7YwjiqAdhTqNdBgOjuO9KaOWHkRULgzjDKVnS1HXgj8I0vvLqQb7kJj /mmw==
X-Gm-Message-State: ALoCoQnVQkEcFwkkZXeMXKBPSBWaoFad7JY9pXUl13OTOTfAGdlNmibO6Jkaxep43qSLdm0AtPwpH5GHE7mEgGDkl4ZK8Rz/5EHKcAlAOFapePbT1bCBy9hckzonPHxyHYsaAbrHNdLw7v2gRAJVRw339EI7beivwlOlhj+rWLy0CPyV/5omHxhk+mH5rk5eRz1INqr/7tp6
MIME-Version: 1.0
X-Received: by 10.52.50.177 with SMTP id d17mr6814124vdo.23.1386124109308; Tue, 03 Dec 2013 18:28:29 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Tue, 3 Dec 2013 18:28:29 -0800 (PST)
In-Reply-To: <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com> <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com> <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com> <CAL9PXLx0+bYn_KXKhvFz=D_jXfctdVihaXnj=SqB6EeEqRLOSg@mail.gmail.com> <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com>
Date: Tue, 3 Dec 2013 18:28:29 -0800
Message-ID: <CALTJjxEDXsmdzY4+OH2AFcYfMW5zY=V4PzQK3hqB1WrqjRJB+g@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Bodo Moeller <bmoeller@acm.org>, Adam Langley <agl@google.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Wed, 04 Dec 2013 02:28:34 -0000

On Thu, Nov 28, 2013 at 4:21 AM, Bodo Moeller <bmoeller@acm.org> wrote:
> Everyone,
>
> the new I-D for TLS_FALLBACK_SCSV is now at
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.

Bodo, Adam,

I read your -01 draft while reviewing your OpenSSL and NSS patches for
TLS_FALLBACK_SCSV.

I have some comments.

1. Why don't you also specify a TLS extension, which can be used when
we fall back to a lesser TLS version (but not SSL 3.0)?

I assume specifying only a SCSV is for simplicity.

2. I don't understand why you want the server to report an
inappropriate fallback only if the client drops below the server's
highest supported version.

This means an inappropriate fallback is not always reported to the
client, or it is reported to the client only after multiple fallbacks.

For example, suppose the server supports TLS 1.1 and the client
supports TLS 1.2.

If a middle box blocks only TLS 1.2 ServerHello and injects a TCP
Reset (this middle box behavior was observed, not hypothetical), the
client will retry with a TLS 1.1 ClientHello with the fallback SCSV,
but the server will then finish the handshake successfully.

On the other hand, if a middle box blocks both TLS 1.2 and TLS 1.1
ServerHellos and injects a TCP Reset, the client will retry twice,
first with a TLS 1.1 ClientHello and then with a TLS 1.0 ClientHello.
Although the ClientHellos in both retries have the fallback SCSV, the
server will only respond with an inappropriate_fallback alert to the
second retry.

I think the draft should explain the rationale for this less strict
server behavior.

3. In the Security Considerations section, we have:

   However, it is particularly strongly recommended to send
   TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher
   suites in SSL 3.0 have weaknesses that cannot be addressed by
   implementation workarounds like the remaining weaknesses in later
   (TLS) protocol versions.

It would be nice to name the weaknesses and workarounds explicitly.
The implicit IV weakness of TLS 1.0 and SSL 3.0 can be worked around
by record splitting, so I assume that's not the weakness you're
referring to. Are you referring to the CBC padding timing attacks?

Also, it seems that the main problem with downgrading to SSL 3.0 is
the loss of features and cipher suites that require TLS extensions,
such as Server Name Indication and ECC cipher suites. You already
mentioned that in the Introduction section. If the loss of these
features and cipher suites degrades security, it should be mentioned
in the Security Considerations section as well.

Finally, the fallback to TLS 1.1 loses AEAD ciphers, and the fallback
to TLS 1.0 loses the explicit IV for CBC block ciphers (although the
record splitting workaround is effective). Perhaps these should also
be mentioned.

Wan-Teh Chang