IETF Logo Mail Archive

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

Fabrice <fabrice.gautier@gmail.com> Wed, 15 October 2014 08:50 UTC

Return-Path: <fabrice.gautier@gmail.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 5D4031A19E4 for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 01:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 kbUORperIYkq for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 01:50:17 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345B61A0AFE for <tls@ietf.org>; Wed, 15 Oct 2014 01:50:17 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id y10so874397pdj.37 for <tls@ietf.org>; Wed, 15 Oct 2014 01:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NFLoKTQ62TYuDKOLs+ymZ+wb4VnSMmqjLqupX1feZ5w=; b=JMetfeB8+HoihUINwHBb3NeroDB0vJrzIZZno4FrCkxMh9aXlOW4xUyKeUFOcwEBI3 P/iynIhQita6cB3OePZUlhU6wtebaWEeWumc6TAB0AbVb20dp8jttGfWAYt51aBjiEl2 cIL0qcctem+Rthqe4JAi1+fbyjl0t2DYNgvzwrv+PzVv/fSZtFdiW/Z3gkYRuvl93Oy2 8hpmtbU+d1xq//RUD+foeb/M+HvQ63gsg8XCJP28eUUerlKCm7hN5WWAWZvA98M46qjr /SRQY37RMyYqoZaC7a/CPk58rAilSrw0ebuHmpfakTgiLAxcWyM2TZei6c6rYGH5DHPi rHdw==
X-Received: by 10.66.65.162 with SMTP id y2mr10392320pas.57.1413363016879; Wed, 15 Oct 2014 01:50:16 -0700 (PDT)
Received: from [10.0.1.6] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id a12sm2469153pdm.64.2014.10.15.01.50.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 01:50:15 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (12B411)
In-Reply-To: <543E2D81.1050700@redhat.com>
Date: Wed, 15 Oct 2014 01:50:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cuzAPqv0ouBPlgjz7jbD_FRkkfI
Cc: "tls@ietf.org" <tls@ietf.org>
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 08:50:21 -0000

> On Oct 15, 2014, at 01:17, Florian Weimer <fweimer@redhat.com> wrote:
> 
>> On 09/26/2014 06:00 AM, Joseph Salowey (jsalowey) wrote:
>> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.
> 
> I'm strongly against this proposal.  It severely punishes those who have correctly implemented the protocol all along by forcing them to upgrade their code base, for the benefit of those who fail to interoperate (or who want to interoperate with those who fail).

I don't see how this force anybody to implement this or punish anybody who doesn't. 

Even if the majority of implementations were to implement this, they would still interoperate with the ones that don't implement it.


> 
> We need to get rid of broken implementation, not cater to them indefinitely.  With this mindset of unlimited workarounds, no protocol versioning mechanism (including the one proposed here) will ever work securely because implementations will be forced by overriding concerns to ignore protocol failures, against better judgment.

Unfortunately, interop with broken systems is pretty much a requirement in many cases. 
Without the workarounds such as retry and fallbacks, I believe the adoption of newer, more secure, version of TLS would be even slower. Catering to broken implementation may actually help in the long term, I think.


-- Fabrice

v2.23.0 | Report a Bug | By Email