IETF Logo Mail Archive

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

Bodo Moeller <bmoeller@acm.org> Mon, 20 October 2014 20:12 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 08E121A9107 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 13:12:29 -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 IFpflz91RDDz for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 13:12:28 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 B417C1ACD91 for <tls@ietf.org>; Mon, 20 Oct 2014 13:12:27 -0700 (PDT)
Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0LnX58-1YLhXt0aCc-00hiSU; Mon, 20 Oct 2014 22:12:23 +0200
Received: by mail-yh0-f53.google.com with SMTP id b6so3898386yha.12 for <tls@ietf.org>; Mon, 20 Oct 2014 13:12:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.231.116 with SMTP id k110mr7534857yhq.127.1413835941894; Mon, 20 Oct 2014 13:12:21 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Mon, 20 Oct 2014 13:12:21 -0700 (PDT)
In-Reply-To: <460682079.47331533.1413825491684.JavaMail.zimbra@redhat.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.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> <CADMpkcJZ_rm5U+vKoUdX03Jbotbf4zeJoVU=KB3CSJg=tX05fQ@mail.gmail.com> <1413807699.2597.14.camel@dhcp-2-127.brq.redhat.com> <CADMpkc+C269mpomY7CWF0UNyRh5V9jdqMq59ZqdJ8Z9CMNiuBQ@mail.gmail.com> <460682079.47331533.1413825491684.JavaMail.zimbra@redhat.com>
Date: Mon, 20 Oct 2014 22:12:21 +0200
Message-ID: <CADMpkcKfawMPm=p8CvoHqZiWtJ7TqBvzLKj0ZnDOoSZNj5oNVQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e0160a27416636e0505e0556a"
X-Provags-ID: V02:K0:h/PLGyBVSmDbQnz4fPXXRH9Wi8qrudJsziJuEghHO+8 34aVZLAG/2KIU3P0QCkNI1W9qSUZvxcLR5HmIujII6WmDAGrMO SxJs6VG6tk63RTh3O+/9sr7kHymMLTCXlZOoXdpmYdipre8vjY qiUxh53gxFmiwabU5xuZJSj5ELQ3yAu6jcXcUZvAj8PkXPpVQt GAY6j2YNVWk5k9C2DlKK7fU6GYxKQ7s/YtYIETf0Piu89zJBy4 lJW7Z3mDszpc3sbcdnhdnU8egyjUUykLkc4Gq+AmAPWyTUBSxy QS+sqXe6OKROJ9/WDMPm+kR7FclySyRvsjjxNQLBxdd/sesx60 yQstjnyj9BKXixVppTZObOSUbb4Olgk4Dak+cEb0gr8KGwiAyz 2RptMVbZy7cbsZEazBDl3WwVfjRM26LuYCT1OPV5Jp3iiRgvJc J4JFI
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tcMFVG_gZLr4BIGrKlPwAqq5Vxw
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 20:12:29 -0000

Nikos Mavrogiannopoulos <nmav@redhat.com>:

With this change, clients still consider the servers that
> require a downgrade dance secure. Why should that be the case? Why for
> example
> chrome or firefox doesn't warn on these servers? They are certainly not
> secure.
>

I'm not sure why you think that the TLS_FALLBACK_SCSV specification should
be setting UI requirements for this. The same protocol versions, negotiated
using the normal version negotiation mechanism, are just as secure or
insecure, so this isn't specific to TLS_FALLBACK_SCSV.

Bodo

v2.23.0 | Report a Bug | By Email