IETF Logo Mail Archive

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

Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 15 October 2014 11:04 UTC

Return-Path: <nmav@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 D69321A1A87 for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 04:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 fxGHG7eADq_f for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 04:04:03 -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 6E2471A1A86 for <tls@ietf.org>; Wed, 15 Oct 2014 04:04:03 -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 s9FB3xid010600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 07:04:00 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FB3vi9015177 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 07:03:59 -0400
Message-ID: <1413371037.15961.26.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Fabrice <fabrice.gautier@gmail.com>
Date: Wed, 15 Oct 2014 13:03:57 +0200
In-Reply-To: <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eet40y8kHzL4Bm8InB6_Wvshucc
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 11:04:06 -0000

On Wed, 2014-10-15 at 01:50 -0700, Fabrice 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. 

Of course, but then what is the point of standardizing it? In any case,
I don't believe how adding support for this extension on every
implementation (in order for the protection to matter) is easier than
fixing the few broken servers that don't properly do version
negotiation. I believe there is little point for this protocol
extension, given that the work arounds for the applications that use
non-standard version negotiation are very straightforward (disable SSL
3.0).

regards,
Nikos

v2.23.0 | Report a Bug | By Email