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

Bodo Moeller <bmoeller@acm.org> Fri, 26 September 2014 18:53 UTC

Return-Path: <SRS0=QEdY=6T=acm.org=bmoeller@srs.kundenserver.de>
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 384751A3B9D for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 11:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level:
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
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 POeDoEnTdjcU for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 11:53:40 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746801A3BA4 for <tls@ietf.org>; Fri, 26 Sep 2014 11:53:22 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0LkxjZ-1Y5Gxu4BlN-00aqWf; Fri, 26 Sep 2014 20:53:20 +0200
Received: by mail-qa0-f53.google.com with SMTP id cm18so6333996qab.26 for <tls@ietf.org>; Fri, 26 Sep 2014 11:53:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.21.104 with SMTP id 95mr840497qgk.69.1411757597944; Fri, 26 Sep 2014 11:53:17 -0700 (PDT)
Received: by 10.140.156.5 with HTTP; Fri, 26 Sep 2014 11:53:17 -0700 (PDT)
In-Reply-To: <ceda19c3fdee4b488cff118d34f44afe@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>
Date: Fri, 26 Sep 2014 20:53:17 +0200
Message-ID: <CADMpkcJPdWemzB6ZFvBEGqTCKzM=mh2-j5gTt_NY+9uVg8prbQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11c152a22273b20503fc6e00"
X-Provags-ID: V02:K0:mqv4MLQK9gVshNwKyFTXEEd0iKtkuF/73wJg8v/u3gk a4RPSlCOiG3da1D70eJOSduX2YL6QirTTF2r8SAowfBxmiEv1v 6+M34bTzyrlUsqh3QtZbFOHSnc4GKhR7KJDGi8/udk49QKCTO7 tojk+BMAAIJZRfmZnL8aekz5M2e4Xg18vpgyEgmzqNR6SAGM3D 34rfSZk8A1jpvFXqX/8rKqHF2Ro3pdXctNI8F9nG5iCcLjB5ly bmFR+5dacXyhWMLaHHe9G/CKiRa7xZ/j8SvpZpt3TL2N0QHvKa zcdL8bb6CaJUZc5r4VANAbY76e0XTO1yhvOWTyR3PH0SxmTAtx yr2LLVUMt+CTnCCAjM040mDaYxtwmKxIxVzG/duhdGuxMphQYn CS6TRJsn2Iy4SU7PV7rH2ra04ZnH0fb+FGf6BQc3j0H8Ux70CX Kr7LF
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2aCT6EhlH4Al4va9b0N8o3befjw
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 18:53:41 -0000

Andrei Popov <Andrei.Popov@microsoft.com>:


> Regardless of what the browser wants to do, the system admin will
> sometimes disable a specific TLS version machine-wide (or enterprise-wide),
> e.g. due to version-specific security concerns.


That's not supported with normal TLS version negotiation either -- if the
client offers version X, the server may pick Y (< X) without having any way
of knowing that Y is disabled in the client whereas some other version Z (<
Y) is not.

If you really see a good reason to support this (which I don't) and are
concerned about latency, you'd already need some TLS extension to send this
information from the client to the server. I've never seen anyone propose
this, and would be skeptical about it.

I am pointing out that, with the current draft, the browser is forced to
> not send the SCSV when skipping versions.


I'd rather say that the client is forced not to skip versions when sending
the SCSV (and that this is a feature).

Bodo