Re: [TLS] SCSVs and SSLv3 fallback

Trevor Perrin <trevp@trevp.net> Sat, 06 April 2013 04:41 UTC

Return-Path: <trevp@trevp.net>
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 45B6321F9797 for <tls@ietfa.amsl.com>; Fri, 5 Apr 2013 21:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.426
X-Spam-Level:
X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=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 0cDtb4waiZmF for <tls@ietfa.amsl.com>; Fri, 5 Apr 2013 21:41:34 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 69BE821F9757 for <tls@ietf.org>; Fri, 5 Apr 2013 21:41:34 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id r3so3374639wey.17 for <tls@ietf.org>; Fri, 05 Apr 2013 21:41:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6wHI190n/JuCX/yKZDOcMgtw2SP2Lclii0hspyQ2/+E=; b=KfluGTR1e+MtOb9iZ+rTSRauIqrxAeNrNaOh+azHD1puuVA7TtVSpUXAAPGL44BJes stsIMVbSSx9Q+27HiqHDt5B1k4ZQ7VeYvZDuBXoGiEmFVePbD/HdlnylrnSe3NEg7qw+ Wyfp2QbiCvF5LPC6qVPKZkrlGAcHJc9Jy+hhexOkPMhxPYLATILS5/WzT5RplC7pnMqS bZCKU/oTS75jS7uNsrnv79MfRtLs0hhXTiSrhLVbOHt4RxI75hoELOaj39a7Qawzwzsd c3n8NdKYeofSzwdTIrm1wAzNKbOdlUl67qcP4mA7H7frSN7tAx180iVfZb7rcEZV01PG yDDg==
MIME-Version: 1.0
X-Received: by 10.180.87.170 with SMTP id az10mr2449718wib.3.1365223293499; Fri, 05 Apr 2013 21:41:33 -0700 (PDT)
Received: by 10.217.119.134 with HTTP; Fri, 5 Apr 2013 21:41:33 -0700 (PDT)
X-Originating-IP: [173.164.206.245]
In-Reply-To: <op.wu3cctbc3dfyax@killashandra.invalid.invalid>
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> <D4CC5248-B1F1-498E-8058-5E17BADB3CE6@vpnc.org> <CAGZ8ZG2uvKs8-Sn9bvQyaP9t_E3BhkZFoi7Sq9wbxaHNpf_NDg@mail.gmail.com> <op.wu3cctbc3dfyax@killashandra.invalid.invalid>
Date: Fri, 05 Apr 2013 21:41:33 -0700
Message-ID: <CAGZ8ZG3H6wPnLZE3CkBGHMiMXvdA-VBM911t+tzPqW5ggJr2PA@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: "Yngve N. Pettersen" <yngve@spec-work.net>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQk05H9vgJvp4XRptncT+NMIXj9HYF4OOZskdPC2p97896sX3mwNFdTLMZNVS30+O5cFxQON
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: Sat, 06 Apr 2013 04:41:35 -0000

On Fri, Apr 5, 2013 at 4:18 PM, Yngve N. Pettersen <yngve@spec-work.net> wrote:
> On Sat, 06 Apr 2013 00:47:16 +0200, Trevor Perrin <trevp@trevp.net> wrote:
>> On Fri, Apr 5, 2013 at 3:19 PM, Paul Hoffman <paul.hoffman@vpnc.org>
>> wrote:
>>> 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.
>>
>>
>> Well, we're agreed this might fix the problem for some middleboxes. :-)
>>
>> The alternative, in the TLS-intolerant middlebox case, is... what,
>> exactly?  Fail to connect?
>
>
> Given that we don't know what these middleboxes react to, using SCSVs might
> work for some, but not others,

Agreed.


> The danger is that by using an SCSV we might "fix" the problem for one group
> of users, and completely break SSL/TLS for another group of users

Suppose the SCSV is only allowed in the specific case of an SSLv3
fallback where an extension response is required or the connection
will fail (due to a requirement for TACK, CT, or OCSP).

In this case, it can't break anything because the connection is
already going to be broken.  It's not guaranteed to work, but there's
evidence it might.

Does that address this concern?


> Bottom line: Assume that Murphy's Law applies; if something can be done
> wrong, then somebody will do it wrong. And in terms of these middleboxes,
> somebody have, but we don't know how many ways they have done it wrong.

Sure.  What data do we have?

Does the estimate of 1/1000 connections between (TLS-capable clients
and servers) getting an SSL3 fallback seem right to you?

Do you have any idea how much of that is general network problems vs.
middlebox problems?


Trevor