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

Bodo Moeller <bmoeller@acm.org> Mon, 20 October 2014 12:13 UTC

Return-Path: <SRS0=BZpw=7L=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 183731A86EF for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 05:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
X-Spam-Status: No, score=-0.938 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dx6jlNdojMkB for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 05:13:14 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (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 C9EBF1A7035 for <tls@ietf.org>; Mon, 20 Oct 2014 05:13:13 -0700 (PDT)
Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0LoJRp-1YM6IB3Pkf-00gDEU; Mon, 20 Oct 2014 14:13:11 +0200
Received: by mail-yh0-f49.google.com with SMTP id a41so2958902yho.8 for <tls@ietf.org>; Mon, 20 Oct 2014 05:13:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.108.164 with SMTP id q24mr3201827yhg.131.1413807187688; Mon, 20 Oct 2014 05:13:07 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 05:13:07 -0700 (PDT)
In-Reply-To: <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com> <CADMpkcLnOh3HGD+urWuo6fPfkX4WfGhwckE0jg5jS2KqD2RuMQ@mail.gmail.com> <CABkgnnWuCwOGBXG2RdetwPFn4KtVPygSBWG5qkme1mvNst6n+A@mail.gmail.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org> <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com> <CADMpkcLf+p5J600gueqzKec4nKuo78Xrr-auW+fyapuqM13Z4w@mail.gmail.com> <1413805668.2597.10.camel@dhcp-2-127.brq.redhat.com>
Date: Mon, 20 Oct 2014 14:13:07 +0200
Message-ID: <CADMpkcJZ_rm5U+vKoUdX03Jbotbf4zeJoVU=KB3CSJg=tX05fQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c1c9fc3404360505d9a32a"
X-Provags-ID: V02:K0:Pr0wgq5nO0WwhiL9TV9DQW8PVLYUajbzEhoUfLDhJZh jlAmS9vlcUYxzArlkvgn+YpJ+1UqAJIvwahSdWU0zghFHLLemP KbdM2cFz/nJ1VblTBLPzXuVcjdqMBGZkEi6fpfeVwoWKhZJWdD 68StqvJgisCSDuqI8bxCPnDxJyBJiR/FSFMZ9UGMpZljb6zvOa 8uTD782HMoh/asrnp1yp9Weww3tG6uGnwrNgsXqQ7Fdu9uUiHQ 1ys9OGnFC+2jT2LIm8DsRwxL2xDD4hB+9u5Q+OxXTpAXdgcfOH rqZj4oIEZxX9suKe4F6AE9gdFXM2IusnW/ND8Zxp9SULGkfRFc 49gtdMF2DLxClgZC33ROGDH+AuiBEY9oBoHPMBDldkUeEQN1rw LGsomySTb9WhJFgQMl4YcDvM1VdXYDNIeSMp/bazRAC3TYxT9c 9EyJP
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ma10AuJiqoDk4GFzRLsz1WqkUSk
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: Mon, 20 Oct 2014 12:26:48 -0000

Nikos Mavrogiannopoulos <nmav@redhat.com>:

Indeed, there is an arguments to keep that mechanism, as there are still
> some TLS 1.3 intolerant servers. But instead of prolonging the life of
> such an insecure mechanism wouldn't it make sense to fix those broken
> servers instead; e.g., by peer pressure by documenting the
> implementations that are not TLS 1.3-ready in [0]?
>

It certainly makes sense to fix those broken servers. I disagree with
fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
false dichotomy. If you are willing to stop fallback retries in the client
products that Red Hat distributes right now, great (do you?), but clearly
not everyone is willing to take that step at this time. Until it has
happened, clients already can benefit from TLS_FALLBACK_SCSV.

Bodo