IETF Logo Mail Archive

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

Brian Smith <brian@briansmith.org> Fri, 26 September 2014 19:05 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 CA37A1A6F10 for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 12:05:25 -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 WKqxHqs1L9Iu for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 12:05:23 -0700 (PDT)
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16C31A00AE for <tls@ietf.org>; Fri, 26 Sep 2014 12:05:23 -0700 (PDT)
Received: by mail-oi0-f54.google.com with SMTP id a3so10274766oib.27 for <tls@ietf.org>; Fri, 26 Sep 2014 12:05:23 -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; bh=I6KlL6kufX3DWu2eY+rzys/paR9m9CgJyyHZEvuiUuo=; b=MVjUdRcBLKeuoyFRGLeueYBguzbPaqUk9OH4mh+RIIcxb3vCA1t7cajAn7wyaCzAC0 8R12OXWsw6brpY6jeyM8e0u9PcD2HFvLvFEKvrxbtqcwNBhDvO/iMCCdsh7MVhaqKWxz kbyQQqdLB96oCTPr2obz4J1yyUtbTADy7KbtBSGLEAmhFEW8KVQTHeawshs0byNPmDVT rEcX/6Lpm35XSsXizN8Au0sCsm9tBwCaY3tW9COjd7oMX8RMI56GjsXYD5Yr5aGQ5X3p pKn7aC2OCUqpOAcW1ORqnEqWO8JJsNDU0N4idPxlWkveoa60bBzniYp7yb8frXTJC/uv oDsw==
X-Gm-Message-State: ALoCoQk2EZ4cdn7UBhF50aX3f72qB97K3MB65A3dRuPjOYPbHCpeXhOBmCZzbC71kExfFgNTNS5p
MIME-Version: 1.0
X-Received: by 10.60.38.67 with SMTP id e3mr23673609oek.62.1411758323082; Fri, 26 Sep 2014 12:05:23 -0700 (PDT)
Received: by 10.76.74.36 with HTTP; Fri, 26 Sep 2014 12:05:22 -0700 (PDT)
In-Reply-To: <3217718b166c44b887feaab052335509@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <e2ae0847d4ef49c48fe972adead9bbcc@BL2PR03MB419.namprd03.prod.outlook.com> <CAMfhd9UQ1wHFMJpLcxX6o3YDcLn_Az_vy7PfB9QUwyjHrrPaJQ@mail.gmail.com> <ceda19c3fdee4b488cff118d34f44afe@BL2PR03MB419.namprd03.prod.outlook.com> <CADMpkcJPdWemzB6ZFvBEGqTCKzM=mh2-j5gTt_NY+9uVg8prbQ@mail.gmail.com> <3217718b166c44b887feaab052335509@BL2PR03MB419.namprd03.prod.outlook.com>
Date: Fri, 26 Sep 2014 12:05:22 -0700
Message-ID: <CAFewVt7UxS2eKpsTMsDdyNUp0JzkuqpMig6O3EaN6jFZQgLcAg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0qQn75DVUBo1NUgUGheVayNEMWg
Cc: Adam Langley <agl@imperialviolet.org>, "<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: Fri, 26 Sep 2014 19:05:26 -0000

On Fri, Sep 26, 2014 at 11:58 AM, Andrei Popov
<Andrei.Popov@microsoft.com> wrote:
> I agree that the client app is forced, but disagree that this is a featureJ.

I think the goal should be, in the long term, to remove the non-secure
downgrade bug from the clients. The semantics of the current draft are
aligned with that goal. Additional features were added to the
mechanism to allow for version skipping would be incompatible with
that goal. In other words, the feature/bug where the client system
administrator can disable arbitrary versions of TLS (e.g. TLS 1.0
enabled, TLS 1.1 disabled, and TLS 1.2 enabled) depends on the client
having the non-secure version downgrade bug, and thus seems like a bad
thing, all things considered. (We considered allowing that kind of
flexibility in the NSS API, and decided against it, for this reason.
So, in NSS, you can choose which range of versions to use, but you
can't poke holes within that range.)

Cheers,
Brian

v2.23.0 | Report a Bug | By Email