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

Brian Smith <brian@briansmith.org> Wed, 15 October 2014 20:42 UTC

Return-Path: <brian@briansmith.org>
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 401DD1ACD05 for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 13:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 5oF7InzB53pp for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72DD1A88F3 for <tls@ietf.org>; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id vb8so1756842obc.17 for <tls@ietf.org>; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iyHjlhLfGLNsRybJtfb0eMaxCUtGFeN6uWCcNAcSn3k=; b=lgV6eICoIMhueFjjPIpQvbFsdcBVOCQV/6anrnvJfszRy/ddWPnge2VPwPNNkoTkJz RxC5maxlPAHttuV4KKcW2p7DnHbPX8RhpJHOUHAsaJtZYgCtBUeSd7LsOnbARvZeJEOh lYcczPH3o2KKIdUBXn+1CfiKFs21ktScMicN57ONIKNmBgQQkS/Dw7l+yWl3Wh/aMT3J OmmwGoqugZGqDvt3aDMnwpv2dDFOZRxBDfcpgxLZdE+9lts3FiHMq1Fe+bEgyxvgxoym Napb0C58nA7C4SLmb/B1aYinUIRdTk1KX8DAUhg+3KOYcH1vP84mh4uwUyK1I2JkgQg1 nmbQ==
X-Gm-Message-State: ALoCoQnW/IepUVjY7mPTR9ZljKy/yvtS+lkpzyH4bDrMKg2HOhdf2a2q2YhFl22FC9KAc3jZsx3/
MIME-Version: 1.0
X-Received: by 10.60.16.2 with SMTP id b2mr2946446oed.82.1413405739181; Wed, 15 Oct 2014 13:42:19 -0700 (PDT)
Received: by 10.76.93.9 with HTTP; Wed, 15 Oct 2014 13:42:18 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543E2D81.1050700@redhat.com> <7F8CB03B-6882-41E7-9705-7126A8F2F44D@gmail.com> <CADMpkcJLrQEtiUGi9B7ZS5402cXTBvvThL9-YwUUhncaXQaVsA@mail.gmail.com> <20141015140158.41a1faf8@pc.my-domain> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE841@USMBX1.msg.corp.akamai.com>
Date: Wed, 15 Oct 2014 13:42:18 -0700
Message-ID: <CAFewVt7gPWKtyjUFSsURN3O5ys0YJLLSAXPTTgD8VKm_Gm_vDQ@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/16h4wjI2gQAVhwLkS3y0_OBbm-A
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 20:42:21 -0000

On Wed, Oct 15, 2014 at 5:19 AM, Salz, Rich <rsalz@akamai.com> wrote:
>> Can you quantify that tradeoff? How many devices are there really out there
>> that would break? I'd like to have this discussions with hard numbers.
>
> We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and it's concentrated to a few particular clients.  Those clients are important to some customers. They want modern browsers to be protected, by not falling back to SSLv3, but they don't want to cut off those legacy clients.  SCSV fallback solves that problem.

That problem is also solved by the browsers simply not doing the
non-secure fallback to SSLv3.

> It also will solve a problem when some browsers try to use
> TLS 1.3 but servers haven't been updated.

If TLS 1.3 is still planning to use the version negotiation mechanism
to negotiate TLS 1.3, then that's a defect in TLS 1.3, for this
reason. That defect should be addressed so that the downgrade SCSV
will be a non-issue for TLS 1.3.

Cheers,
Brian