Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Florian Weimer <fweimer@redhat.com> Wed, 15 October 2014 15:20 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 C0FA01A86F0 for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 08:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C6pEM1y8gXSy for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 08:20:14 -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 78E931A1B1C for <tls@ietf.org>; Wed, 15 Oct 2014 08:20:14 -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 s9FFKCcx027931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tls@ietf.org>; Wed, 15 Oct 2014 11:20:13 -0400
Received: from oldenburg.str.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFK9C8008667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <tls@ietf.org>; Wed, 15 Oct 2014 11:20:12 -0400
Message-ID: <543E90A9.5030003@redhat.com>
Date: Wed, 15 Oct 2014 17:20:09 +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: tls@ietf.org
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com> <CADMpkcJLrQEtiUGi9B7ZS5402cXTBvvThL9-YwUUhncaXQaVsA@mail.gmail.com> <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com> <20141015143611.1c7b079b@pc> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE85E@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE85E@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/9MHKuPcLjNOg4B0e6pl_EgSfSyQ
Subject: Re: [TLS] 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: Wed, 15 Oct 2014 15:20:19 -0000

On 10/15/2014 02:43 PM, Salz, Rich wrote:
>> So the number I want to see is: How many servers are there that are not
>> capable of correctly negotiating the SSL/TLS versions they support?
>
> That's not the question that SCSV is trying to address.
>
> The question is:  how many clients end up using SSLv3 when the could use something better?

But the new SCSV will make things worse for accidental protocol 
downgrades (which happen quite frequently with Firefox, it seems).  What 
is now a protocol downgrade will turn into a hard connection failure.

Will the new SCSV enable additional clients to switch on more recent TLS 
versions by default?  I don't think so—you'd still need to code the 
fallback logic separately and outside of the TLS implementation (e.g., 
to support things like STARTTLS, which the TLS implementation typically 
doesn't know about).

-- 
Florian Weimer / Red Hat Product Security