Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Bodo Moeller <bmoeller@acm.org> Mon, 27 January 2014 11:41 UTC

Return-Path: <SRS0=Ipyw=XB=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 DEEE71A01E8 for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 03:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.464
X-Spam-Level:
X-Spam-Status: No, score=-1.464 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.535, SPF_HELO_PASS=-0.001, 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 nbMyKMLcd88r for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 03:41:04 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 40D161A01E4 for <tls@ietf.org>; Mon, 27 Jan 2014 03:41:04 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MbsGc-1VoQiz1Qn8-00JhFz; Mon, 27 Jan 2014 12:41:00 +0100
Received: by mail-ob0-f181.google.com with SMTP id va2so6266206obc.40 for <tls@ietf.org>; Mon, 27 Jan 2014 03:40:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uLshMShztkqcl6w5WydKqU17DB/GLMLuMJXlAtPr3z4=; b=JR2lLdbB0i0B5QQnfbbMwkC4mwdRRH3I9712qIqZjezHffWF8/IT/z7X43v+MQbPG5 siIuLsQtlycZTacSVay6C7Xi78VJvp7SB//h8CJCOoIVrLxGjMyZ82kSKsO9Lc+WQq8h coFMHn7p2NhLN2TNOzWdgVZMF9Yn1OXVMc/wQQlkqgU/pNFaUKWjGgZywf8bu1CRrp9q ZxcuZjuqfkEvXeRszc9R90X2+XMOBYowUPK6t9SwVKjdWXe7f7SPPM8/CcsdhSJ45N8t SiBc9khVHanJJsOmLyEBt+HPG0KVPk1+rv5d5k/wJ7K0CVHuTXlH8Vgha41C39ecG+RL PhkA==
MIME-Version: 1.0
X-Received: by 10.60.119.70 with SMTP id ks6mr803203oeb.45.1390822855868; Mon, 27 Jan 2014 03:40:55 -0800 (PST)
Received: by 10.60.170.239 with HTTP; Mon, 27 Jan 2014 03:40:55 -0800 (PST)
In-Reply-To: <20140125042425.230961ABCA@ld9781.wdf.sap.corp>
References: <52E2DA85.4010705@fifthhorseman.net> <20140125042425.230961ABCA@ld9781.wdf.sap.corp>
Date: Mon, 27 Jan 2014 12:40:55 +0100
Message-ID: <CADMpkcKB3E=KZUZVoHQqxV+cmDOPHPM+Q1n-hj8291nSpNF8OQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b33c91445def704f0f22e16"
X-Provags-ID: V02:K0:M/wxpVb9stnA3RURq2N4JwkI/+v8Q4o4YlhjC13hzCF pi7k+G5S8+/SYJtqN0DQsAKpfyUEn75ELWDCu1vbZ/F/soCDOZ kay6lF3pRnsc5ar5YBtwhzNcmzRHuhyQGP0666FOCHE9NGLL73 ucnlwHsdEQHi/5uKSMBjlwsJ1ahJzQ8SxIHsqrE0Lg0ElAzdwm 7sOQzIydQTnOR0KPOq9a25x7wx+DyLJNx3HzWhKAGVAqyReDI9 ePz5cUP0rx1fmyGxNCX0r2h/432Xfn54cF2ejJlBzqgQjoX9YH b1DU2Vnk/xc1zK5y1rd5PF8r152QygtfmnkVSJw2M6i57P6rvj 5/7622X892d8uWduhyszM7ugJ50t194sS74Xlp3MMdGr2KZJR1 3v9Ra3b8FvQ0RUZKIaJHbQNH5D1+WISzPLVExazCs7oZVGHckL CuLR/
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
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: Mon, 27 Jan 2014 11:41:06 -0000

Martin Rex <mrex@sap.com>:

> Daniel Kahn Gillmor wrote:
>


> > By transmitting this SCSV, the client is saying to the server "just so
> > you know, i tried a better protocol, but it didn't work -- if you meant
> > to accept better protocols, then someone is messing with us, please
> abort."
> >
> > The server knows whether it believes it can accept better protocols, so
> > it is in the right position to make this call.
>


> The _only_ reasonable server response of a TLS server that supports TLSv1.2
> to a ClientHello that contains an SCSV which indicates that the client
> (a) supports TLSv1.2 and (b) would prefer to use TLSv1.2
> is a ServerHello with server_version=TLSv1.2.


Well, I guess that this sort of would work: I'd still expect many
connection failures (if a middle box doesn't like TLS 1.2 in the Client
Hello, why would it like it in the Server Hello and in actual use?), but
then with the TLS_FALLBACK_SCSV spec, failures are expected in the similar
scenario too.  Of course, a TLS_FALLBACK_SCSV-induced early abort is
computationally much cheaper than proceeding with a handshake and running
into a failure later.

Also note that TLS_FALLBACK_SCSV as specified in
draft-bmoeller-tls-downgrade-scsv-01
is *not* about having the client indicate to the server that it supports
TLS 1.2 and would like to use that particular protocol version.  To keep
the protocol as simple as possible and entirely *avoid* servers-side
heuristics, the SCSV simply indicates that the client has fallen back below
the protocol version it would normally try to use: maybe it would really
want to use TLS 1.3, maybe it would really want to use TLS 1.1 (but has
fallen back to 1.0).  Trying to do a secondary protocol version negotiating
using SCSVs as sketched by you would be much more complex than handling
TLS_FALLBACK_SCSV, with unclear practical advantages (see above).

Of course, TLS_FALLBACK_SCSV won't prevent you from experimenting with that
kind of fix.  The caveat is that where the current spec has the server look
at ClientHello.client_version, server implementations would have to look at
the overridden client_version value instead.

Bodo