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

Bodo Moeller <bmoeller@acm.org> Tue, 28 January 2014 08:52 UTC

Return-Path: <SRS0=vgwm=XC=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 AF79D1A008A for <tls@ietfa.amsl.com>; Tue, 28 Jan 2014 00:52:37 -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 X4wQFDjT6uMs for <tls@ietfa.amsl.com>; Tue, 28 Jan 2014 00:52:36 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 400B91A003E for <tls@ietf.org>; Tue, 28 Jan 2014 00:52:36 -0800 (PST)
Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MZysF-1Vqf3H3e7L-00KyuC; Tue, 28 Jan 2014 09:52:33 +0100
Received: by mail-ob0-f175.google.com with SMTP id wn1so87367obc.34 for <tls@ietf.org>; Tue, 28 Jan 2014 00:52:31 -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=Gl16s9dR0egtnMw1Nd6eKeLGRy5g7FSifN6H+pUVNc8=; b=mc1yeTQie6Fz6Cy91ZvWT5xzHNC06sSIlbyYb5t2HfqR2JfQmL70u+ibmhS+W0m/0a 78ZfNNWnaPin7BdWjAwcavjcf05lK70XKkdmIpIOqEpZnmK6Bkz/oTF5/LUq9FNpBihg LQ9Sqr/3qMVOvVxMYCmCDxu8Z2R8ETawzaLfuxokKP1trrsRgyLh9xmNaKQlD3uRXBsh iiweNE63lTkmaHDThuxP3/bIOzGysiC6aJKtmmyYsVQNQmHpkckRP+DM1ASfWdjiRWRg JCRtxubGrlladixIUvCHFJN+QUYy6Y1ihgmukiRsXMuz/f64urquB3O2L7+WH5LvOfM0 VqSQ==
MIME-Version: 1.0
X-Received: by 10.182.22.18 with SMTP id z18mr180636obe.42.1390899151658; Tue, 28 Jan 2014 00:52:31 -0800 (PST)
Received: by 10.60.170.239 with HTTP; Tue, 28 Jan 2014 00:52:31 -0800 (PST)
In-Reply-To: <20140128033141.EEEDE1ABC9@ld9781.wdf.sap.corp>
References: <CAL9PXLzGTm-3Ciyg4trja1zYEmOOJ-FTd5zfSTOg95ukpadYPw@mail.gmail.com> <20140128033141.EEEDE1ABC9@ld9781.wdf.sap.corp>
Date: Tue, 28 Jan 2014 09:52:31 +0100
Message-ID: <CADMpkcJiZRJw3r2AAgPZSq=miFGk8GrpayszoCY0BWdC-r9c6A@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Martin Rex <mrex@sap.com>
Content-Type: multipart/alternative; boundary="001a11332d16da649404f103f1e7"
X-Provags-ID: V02:K0:Ui+gX5d30Kl6CwQBQq780KGlIqiWZM+Dna2WPWMKMnL Boj8zdCQdwzVMbdOw8Ww/kAKdYW137Ppz1EToFdP8M+FL9Sqwl bCXXqnGwg6SXl8yeEJRU9llWH0Vy0jVaLfMX/phokmhITTvCXO 2AGSlgAh+RPRlCV5Oo3o1GDY4op+UbmGPdz79JEahTkflWYefT MbSq4lJ48nqiPyd0Q7jj0l9+OOQawmHBPm33TWXw4xf4O0KjQK uKxIuJx1D7ZaFsWaoXnaC1C6M7ieUWEjWH9+qoEbn8WdgcLrfK dWtB5sWv8S5cFt2Dzeo63EzmTu6e4br0H56I3B0B6HDPTgLug2 WxrE7oBRHgqHj+NpOUWyUamRpvsiHuqJfqn7D3vg/Yzj/IMFKU upn/hzT+KaUVZeGejIRXW3MCDC9kpzFVlC2NFnEmOk9/ql07oK tDUPy
Cc: "tls@ietf.org" <tls@ietf.org>
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: Tue, 28 Jan 2014 08:53:23 -0000

Martin Rex <mrex@sap.com>:

The negotiation could work like this:
>


>      Client                                               Server
>
>       minimal ClientHello w/SCSV    -------->
>                                                       ServerHello w/SCSV
>                                    <--------      ServerHelloDone
>       ClientHello                   -------->
>                                                       ServerHello
>                                                      Certificate*
>                                                ServerKeyExchange*
>                                               CertificateRequest*
>                                    <--------      ServerHelloDone
>       Certificate*
>       ClientKeyExchange
>       CertificateVerify*
>       [ChangeCipherSpec]
>       Finished                     -------->
>                                                [ChangeCipherSpec]
>                                    <--------             Finished
>       Application Data             <------->     Application Data
>

Well, it could, but I certainly think it's fair to say that getting this
deployed will take much more design and implementation work than
deploying TLS_FALLBACK_SCSV.

There's actually no conflict here.  TLS_FALLBACK_SCSV provides an
immediately available simple fix for clients that use protocol fallback
strategies.  Later, if and when a more elaborate solution is available (or
if broken servers simply are no longer an issue, whichever happens first),
either clients won't have to send TLS_FALLBACK_SCSV (if there's no fallback
reconnect), or servers won't have to abort the connection (if they are able
to negotiate a non-downgraded protocol version as in your protocol sketch).

(I'm highly skeptical that extending the protocol by another round as shown
in your diagram would be desirable overall and that this would solve a
real-world problem in the real world, but the utility of TLS_FALLBACK_SCSV
does not depend on that question.)

Bodo