IETF Logo Mail Archive

Re: [TLS] SCSVs and SSLv3 fallback

Nikos Mavrogiannopoulos <nmav@gnutls.org> Fri, 05 April 2013 21:31 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110021F98B7 for <tls@ietfa.amsl.com>; Fri, 5 Apr 2013 14:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.846
X-Spam-Level:
X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcRT+W3eKYpD for <tls@ietfa.amsl.com>; Fri, 5 Apr 2013 14:31:02 -0700 (PDT)
Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7C121F98A9 for <tls@ietf.org>; Fri, 5 Apr 2013 14:31:02 -0700 (PDT)
Received: by mail-ea0-f172.google.com with SMTP id z7so1558403eaf.31 for <tls@ietf.org>; Fri, 05 Apr 2013 14:31:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=0tULzIGAoIiphZYUiwqxev0B2FrjkxkLu23EIfKXpdM=; b=PCqLbKTNueIhrzZg3az0zAF7hlmCPpYRJ8Omxg+dtfCNb4jqdZ8WIxRz+unOlNkXMq EMlHoyPuwA5o3Lys1cp0UUNXhk/c2BL262xrVsiS5jSlBOnjN0eGf0KhOG4bn/pu+vw3 hXnX/cv8djQDAezFkNjEmL1EF24OTgg9HlYc54AG9IuDEw6wyGVPwmWuOt1WAmVXUyNm 8uMVsNUHWsPRl90nm+GP+MnNM4vHSF3YFPdYzUNUYm/VKWgBc6F/qkWR7q9/lz4tPgmc wmUbhQLdl9AB+7zpMLDjQ/w3b5hAX45iMhVnSdhHVYdYXCcuk1IXByWsYffcYXBroa2P vmnA==
X-Received: by 10.15.43.73 with SMTP id w49mr22894331eev.12.1365197461152; Fri, 05 Apr 2013 14:31:01 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id f47sm17647444eep.13.2013.04.05.14.30.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 14:31:00 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <515F428E.2010900@gnutls.org>
Date: Fri, 05 Apr 2013 23:30:54 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: tls@ietf.org
References: <CAGZ8ZG0i4-ZDPu=O1+Qy1DJ8oV80_eMz5J9NZrn2UC1-zYu4Sw@mail.gmail.com> <op.wu1f2u2n3dfyax@killashandra.invalid.invalid> <CAGZ8ZG1JzgnCNqfPueKr3wrvMzZKUi7mfvcAdRc-NnCDr33aLg@mail.gmail.com>
In-Reply-To: <CAGZ8ZG1JzgnCNqfPueKr3wrvMzZKUi7mfvcAdRc-NnCDr33aLg@mail.gmail.com>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] SCSVs and SSLv3 fallback
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Apr 2013 21:31:06 -0000

On 04/05/2013 09:46 PM, Trevor Perrin wrote:


>  (c) This proposal is guaranteed to fail with TLS-intolerant
> middleboxes, whereas the SCSV proposal has a good chance of working.

[...]
> I'd be interested in hearing more about why people oppose the SCSV
> approach.  We're nowhere close to exhaustion of the ciphersuite (or
> extension) registries.  Is there some real problem with SCSVs, or does
> it just offend people's sense of the "proper way" to do things?

I wouldn't expect the problem of failed TLS connections due to middle
boxes or bad implementations to disappear by making a complex protocol
even more complex.

By having a protocol that offers more than a way to do things I'd expect
an increase to the interoperability and failed connection issues we see
today. More options for the same thing pretty much guarantees that there
will be at least one implementation that will ship the non mainstream
options untested.

regards,
Nikos

v2.23.0 | Report a Bug | By Email