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

Brian Smith <> Tue, 21 October 2014 06:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 495621AD065 for <>; Mon, 20 Oct 2014 23:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YUZvujNz5Psk for <>; Mon, 20 Oct 2014 23:21:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 370AA1AD012 for <>; Mon, 20 Oct 2014 23:21:51 -0700 (PDT)
Received: by with SMTP id m8so437267obr.14 for <>; Mon, 20 Oct 2014 23:21:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lhbNHiXR/tQo7PzsOpgQPmKNMHxrZybu557l+CtGX7o=; b=F/wJer12s9GQgKlmXaIEQoK5ZTRtBpF1WVeeLEJRywybyXKWJ+cyGn7YF1Nm/0FrhT JZHoUTJ/p58k5EuEpmJDlgD/LoUgc7+TKfSlknR5Sd/6sktc2QvzAgBS7j71cDKlvFiK 4y59oV+VjucuTrGca7DyFtglG6bnDwPk9LNrzzR/8ZNUKmh2HEdqacIVnAlpBiznMDzH lFCiwt/um+bfQM+zd24/IRY2uZjfZcdDXG+Pgf3MJu3AM+LhRP2QHmswVU6YRZxyLh0Y dAP3iYDK1Grp/LnKTkgfJOWPDZzZKhbMWOP//4soxKVU8P4O8qZsjhc8jPFWn2Wp69yV z4HQ==
X-Gm-Message-State: ALoCoQnxO8e7vp17CUMWsqGxdnOaXEZdJgcjAG1MH36NRVyYFXxEG4JJWjJc2hU3ef7Tjle2Svkc
MIME-Version: 1.0
X-Received: by with SMTP id xr1mr27787542obc.13.1413872510578; Mon, 20 Oct 2014 23:21:50 -0700 (PDT)
Received: by with HTTP; Mon, 20 Oct 2014 23:21:50 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 20 Oct 2014 23:21:50 -0700
Message-ID: <>
From: Brian Smith <>
To: Bodo Moeller <>
Content-Type: multipart/alternative; boundary="001a11c1c970c04aa30505e8d85e"
Cc: "" <>
Subject: Re: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Oct 2014 06:21:53 -0000

On Mon, Oct 20, 2014 at 10:32 PM, Bodo Moeller <> wrote:

> Brian Smith <>:
> 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.
> Maybe, but note that this doesn't actually help against the concrete
> problem with old buggy NSS servers (because these don't handle

First of all, even that old version of NSS is not buggy, according to the
spec. My main concern isn't with old versions of NSS. My main concern is
that we do not know how many TLS 1.0 servers actually check the padding,
but we've assumed that all of them do, even though TLS 1.0 does not require
checking the padding.

Note that a 100% conformant TLS 1.0 implementation could add
TLS_FALLBACK_SCSV support exactly as spec'd and still be vulnerable to
POODLE if it doesn't check the padding in CBC-mode records. Again, I think
this is something worth adding to the security considerations of the

For strong protection against bugs in old protocol versions, the only
> option is to disallow those versions completely.

Yes, but TLS 1.0 implementations can mitigate the risk, as most do, by
checking the padding conforms to the TLS 1.0 requirements.

And, so can SSL 3.0 implementations, right? Checking that SSL 3.0 CBC-mode
records conform to the TLS 1.0 padding rules is likely to cause some
interop problems, but those interop problems would be much less severe than
disabling SSL 3.0 completely, right? I checked and most implementations of
SSL 3.0 are following the TLS 1.0 padding rules in records that they send,
including IE6 on XP, AFAICT. It seems to me that that is a better solution
for websites that refuse to disable SSL 3.0 because they feel they need IE6
support, compared to switching to RC4-only for SSL 3.0. What do you think?