IETF Logo Mail Archive

Re: [TLS] SCSVs and SSLv3 fallback

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 05 April 2013 22:19 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 B429C21F9922 for <tls@ietfa.amsl.com>; Fri, 5 Apr 2013 15:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 OerGQNXcYksA for <tls@ietfa.amsl.com>; Fri, 5 Apr 2013 15:19:22 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 205BD21F977F for <tls@ietf.org>; Fri, 5 Apr 2013 15:19:22 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r35MJ4Vq079015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Apr 2013 15:19:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAGZ8ZG2OqLz8NymWzR0WNWsHz7qHLA+8eq95WFTLVFGaTK=RCA@mail.gmail.com>
Date: Fri, 05 Apr 2013 15:19:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4CC5248-B1F1-498E-8058-5E17BADB3CE6@vpnc.org>
References: <CAGZ8ZG0i4-ZDPu=O1+Qy1DJ8oV80_eMz5J9NZrn2UC1-zYu4Sw@mail.gmail.com> <op.wu1f2u2n3dfyax@killashandra.invalid.invalid> <CAGZ8ZG1JzgnCNqfPueKr3wrvMzZKUi7mfvcAdRc-NnCDr33aLg@mail.gmail.com> <515F428E.2010900@gnutls.org> <CAGZ8ZG2OqLz8NymWzR0WNWsHz7qHLA+8eq95WFTLVFGaTK=RCA@mail.gmail.com>
To: Trevor Perrin <trevp@trevp.net>
X-Mailer: Apple Mail (2.1503)
Cc: tls@ietf.org
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 22:19:22 -0000

On Apr 5, 2013, at 3:11 PM, Trevor Perrin <trevp@trevp.net> wrote:

> On Fri, Apr 5, 2013 at 2:30 PM, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
>> 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.
> 
> If the problem is TLS-intolerant middleboxes, then allowing necessary
> handshake data to flow via SSLv3, using a mechanism that has worked
> for other extension data, should make the problem better.  No?

No. You assume that the "TLS-intolerant middleboxes" actually understand real SSLv3, not some very limited and old picture of it. You might fix the problem for *some* middleboxes, at the cost of making the protocol even more fragile.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email