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

Hubert Kario <hkario@redhat.com> Fri, 17 October 2014 13:40 UTC

Return-Path: <hkario@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 53C781ACDF5 for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 06:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OS4GgIbPJQxy for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 06:40:26 -0700 (PDT)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 30C101ACDF0 for <tls@ietf.org>; Fri, 17 Oct 2014 06:40:26 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9HDeM3Y022757; Fri, 17 Oct 2014 09:40:22 -0400
Date: Fri, 17 Oct 2014 09:40:21 -0400
From: Hubert Kario <hkario@redhat.com>
To: Bodo Moeller <bmoeller@acm.org>
Message-ID: <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com>
In-Reply-To: <CADMpkcL2mntDd0dOruziqF0F=xURnqGgd_YkpF+ONzz8v-wQ9Q@mail.gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com> <CADMpkcL2mntDd0dOruziqF0F=xURnqGgd_YkpF+ONzz8v-wQ9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_13104896_336762867.1413553221954"
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: 3+ehLL7PgdlxwfsUvIMgxHHqC0ChYQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fPaGMN67e4ZlZoasSKWhCrN1rz8
Cc: tls@ietf.org
Subject: Re: [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 13:40:28 -0000

----- Original Message -----

> From: "Bodo Moeller" <bmoeller@acm.org>
> To: "Hubert Kario" <hkario@redhat.com>
> Cc: tls@ietf.org
> Sent: Friday, 17 October, 2014 3:20:14 PM
> Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group
> Last Call for draft-ietf-tls-downgrade-scsv-00)

> Hubert Kario < hkario@redhat.com > :

> > [...] I think the only thing we can do to prevent
> 
> > that is to be explicit in the document:
> 

> > "The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connection
> 
> > with the highest protocol version it supports."
> 
> Right, I think stating this explicitly in the spec is probably the right
> thing to do (of course this has been the intended behavior all along).
> Thanks.

> (Arguably the OpenSSL API is too fragile, and SSL_MODE_SEND_FALLBACK_SCSV
> should be ignored in this case. So clarifying that in the spec is not the
> *only* thing we can do to prevent this.

NSS API does allow this too. 

Thing is, we want to have a way to test if the servers are tolerant to future clients 
that claim they had to downgrade. So having the ability to set TL1.2 with this 
SCSV is useful, just like is having an easy to use, widely distributed CLI tool 
(openssl command) that can do this should help with testing and interoperability, 
IMHO. 

-- 
Regards, 
Hubert Kario 
Quality Engineer, QE BaseOS Security team 
Email: hkario@redhat.com 
Web: www.cz.redhat.com 
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic