[TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

Brian Smith <brian@briansmith.org> Tue, 21 October 2014 00:40 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 881251A1A62 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 17:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cWxlQvZMXxNB for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 17:40:47 -0700 (PDT)
Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9081ACF69 for <tls@ietf.org>; Mon, 20 Oct 2014 17:40:47 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id va2so139657obc.11 for <tls@ietf.org>; Mon, 20 Oct 2014 17:40:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=9Zq1zU9jcxmgycoxAY/xeu/wUs/36vaaIr6Xuxbmm3U=; b=VgPnIgwU2/t9kTcbq7qDqogJZrZzAy9Wt9NMxiuCH04kcoiMkQiE43WENheV2X223g CVBhk/ixpiumasSQm7jIHMiozO2fP020FWVuGLrW8wKVamPwbz2CDyUFd5RCtTfxiEuj zRiBIqNzB87fZ9WQuXatcxjk5eg/qtHlHzNznCVzpuC5HtVfP34dsAMc1i5b8PuAWCWK wz66/VdcwTK/gWmYjqXdjARFZPodLJ5O5g5oxZJ0+gxfMwEwy9W3SQ9BLSR4Cmu9Zwtf S89+ETm1zQky70aHfkASIuO8owIcaaasT7Mh8kJkkq5uQpofF7a5OZGNYBMp5a43Nb0C 7pgw==
X-Gm-Message-State: ALoCoQmP4e7HMs9ZFLfIlC/3wlNZxtco8HCjRBj4bQZdNiZyZfySH6CYtmp4FFlPvQJHhIIhrd8h
MIME-Version: 1.0
X-Received: by with SMTP id y203mr24787170oig.16.1413852046967; Mon, 20 Oct 2014 17:40:46 -0700 (PDT)
Received: by with HTTP; Mon, 20 Oct 2014 17:40:46 -0700 (PDT)
Date: Mon, 20 Oct 2014 17:40:46 -0700
Message-ID: <CAFewVt62pXB8+gv5ozPFSvzYeW-MJgE-61dRLpQUEWWs+0UX-A@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Bodo Moeller <bmoeller@acm.org>
Content-Type: multipart/alternative; boundary="001a113d2dfe0659760505e4157c"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H1llV_h0mipMQ0zOywZECed0Q5c
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
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: Tue, 21 Oct 2014 00:40:53 -0000

On Fri, Oct 17, 2014 at 2:56 AM, Bodo Moeller <bmoeller@acm.org> wrote:

> Brian Smith <brian@briansmith.org>:
>> If version downgrades during False Start are to be tolerated, then at
> a minimum the security considerations of this draft must point out
>> that the mechanism is simple to subvert (partially, at least) when
>> False Start is used.
> Exactly, but the detailed recommendations should go into an updated False
> Start I-D instead; I can do that.  Specifically, that spec could say that
> if the client sends TLS_FALLBACK_SCSV in the client hello, False Start
> SHOULD be disabled for that handshake. And then we'll also have to say that
> the client similarly should not use False Start with any protocol version
> for which it would send TLS_FALLBACK_SCSV in fallback retries (since
> otherwise the former recommendation wouldn't achieve anything.)  The
> TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a
> reminder that allowing False Start with older protocol versions can be
> problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV
> can't address.

I agree with you. However, please consider changing some of these SHOULDs
to MUSTs. As it is, every implementation already trivially conforms to the
current drafts, because all client implementations implement all the MUSTs
(the only MUST is that they MUST NOT send the TLS_FALLBACK_SCSV when
ClientHello.client_version is the highest version they support). That isn't

Note that POODLE, or variants thereof, may apply also to TLS 1.0+
implementations. For example, back in 2010, I fixed a bug in NSS where NSS
did not verify all the padding bytes in TLS 1.0 records [1]. Thus, any
server that is using a version of NSS released prior to June 2010 is likely
vulnerable to POODLE-like attacks even if SSL 3.0 is completely disabled.
Further, note that the TLS 1.0 specification [2] does NOT say that
implementations must check the padding; that requirement was only added in
TLS 1.1 and TLS 1.2. Thus, an implementation could completely conform to
TLS 1.0 but still vulnerable to POODLE. Finally, even though the TLS 1.1
and TLS 1.2 specifications do say that implementations must check the
padding, it isn't necessarily the case that otherwise-working
implementations actually conform to that requirement, and there's no way
for the client to check that in a reliable, high-performance, and accurate

Consequently, I think that:

1. Browsers must abandon the non-secure version rollback to versions prior
to TLS 1.2 completely.

2. The downgrade-scsv draft should be changed to say that implementations
MUST always send the TLS_FALLBACK_SCSV when ClientHello.client_version
indicates TLS 1.1 or lower if the client supports TLS 1.2.

So, I believe that your suggestion for client behavior is absolutely spot
> on. My point is just that the very same issue w.r.t. False Start and
> version downgrades exists if the client doesn't do any fallback retries --
> and those who implement such clients shouldn't have to read the
> TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs
> into the False Start spec.

I agree that the False Start RFC should be updated to include this and
other considerations.

> Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
> saying it is surprising that the downgrade SCSV doesn't prevent
>> version downgrades, and that should be fixed.
> Right. I'll mention that potential surprise with False Start in
> TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in
> the False Start specification.