IETF Logo Mail Archive

[TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

Florian Weimer <fweimer@redhat.com> Fri, 17 October 2014 09:23 UTC

Return-Path: <fweimer@redhat.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 E78681ABD3D for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 02:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level:
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZiT9DFH185s8 for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 02:23:25 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C161ABD3B for <tls@ietf.org>; Fri, 17 Oct 2014 02:23:25 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9H9NKrD009047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Oct 2014 05:23:20 -0400
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9H9NIPu031200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Oct 2014 05:23:19 -0400
Message-ID: <5440E005.6000607@redhat.com>
Date: Fri, 17 Oct 2014 11:23:17 +0200
From: Florian Weimer <fweimer@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, Manuel Pégourié -Gonnard <mpg@polarssl.org>, Martin Thomson <martin.thomson@gmail.com>, Bodo Moeller <bmoeller@acm.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com> <CADMpkcLnOh3HGD+urWuo6fPfkX4WfGhwckE0jg5jS2KqD2RuMQ@mail.gmail.com> <CABkgnnWuCwOGBXG2RdetwPFn4KtVPygSBWG5qkme1mvNst6n+A@mail.gmail.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/weEVAObW5357HCEEnwvRkoRjvdM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] The TLS_FALLBACK_SCSV time bomb (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: Fri, 17 Oct 2014 09:23:28 -0000

On 10/16/2014 03:44 PM, Salz, Rich wrote:
>> A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
>> unconditionally.
>
> A widely deployed client might also start injecting line noise into the TLS stream.
>
> We can't control what buggy clients do.  That's not new.

You recently wrote about SSL_MODE_SEND_FALLBACK_SCSV, without any 
qualifications:

“I recommend that you always set that flag.”

<http://article.gmane.org/gmane.comp.encryption.openssl.user/52991>

Unfortunately, you are not the only one who makes this mistake.

I'm now convinced that the scenario I described is extremely likely. 
The problem, of course, is that you will not notice this bug in the 
client application until the server supports TLS 1.3, when it may be too 
late to fix it in the client.

It would be better to say that connections with TLS_FALLBACK_SCSV need 
to fail unconditionally in the server, independent of client and server 
protocol version.  This approach would essentially be a promise of the 
server to be version-tolerant (or a statement of having been updated 
recently, which hopefully amounts to the same thing).  The advantage 
that it doesn't come with the time bomb that has been built into the 
current draft.

-- 
Florian Weimer / Red Hat Product Security

v2.23.0 | Report a Bug | By Email