IETF Logo Mail Archive

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

Bodo Moeller <bmoeller@acm.org> Thu, 16 October 2014 14:34 UTC

Return-Path: <SRS0=Aa5u=7H=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 6B8741A1B01 for <tls@ietfa.amsl.com>; Thu, 16 Oct 2014 07:34:18 -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 2DiRNnZKQ3Jw for <tls@ietfa.amsl.com>; Thu, 16 Oct 2014 07:34:17 -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 D14341A1A7F for <tls@ietf.org>; Thu, 16 Oct 2014 07:34:16 -0700 (PDT)
Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MC7ge-1XW0gg1wTw-008rlH; Thu, 16 Oct 2014 16:34:14 +0200
Received: by mail-yk0-f180.google.com with SMTP id 142so1173571ykq.25 for <tls@ietf.org>; Thu, 16 Oct 2014 07:34:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.26.229 with SMTP id c65mr2024938yha.13.1413470051421; Thu, 16 Oct 2014 07:34:11 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 16 Oct 2014 07:34:11 -0700 (PDT)
In-Reply-To: <1413468247.17221.8.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>
Date: Thu, 16 Oct 2014 16:34:11 +0200
Message-ID: <CADMpkcLf+p5J600gueqzKec4nKuo78Xrr-auW+fyapuqM13Z4w@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c1c80850d6b405058b2442"
X-Provags-ID: V02:K0:4j42ZuU35SbJ36y0CGbdd4s8mvsEIZEGNl7RR7bRXa7 52ITxjcpje0vKJF+jiiizeKNVdZMH2uwsFKVRQbJOUfIv/MmsW ewFl2glKJTkGRjkBE7m2tdPuyCDTd4H/93oHygCe0HkQk3vx7p tYivAHpcH2hzteSv1EQiCR5Vbg6qmQWlxveUORnuG+narV9y7b 7q2YNB9cn8BrqxyxCMU8Z11F3BPsPWWGt69Wzdee/qbqrkQN+j CNFTrcTnARX2hftdFlLGywg90rJnmkbzrsCUXLg3Ty6QbYziPq dgXPcL0hliBQmoxJzj/WjoY6CIXAAulZL8WWaXodAvyPs4/XiE HI94L/Z906bvH0hE3LUod3n30ald9M0smriZEvXyc0l/aqp49W i+mAdE+TsT22oxBz+XF4DGNEzZBQQIPTosS3rrzxEI9ajGJ+uk 8K/t6
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DdftWarEraFpkYhUFXUBdkPX0Ak
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: Thu, 16 Oct 2014 14:34:18 -0000

Nikos Mavrogiannopoulos <nmav@redhat.com>:

> > A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
> > > unconditionally.  This client would break once servers start supporting
> > > TLS 1.3.  That's just one example of what could go wrong which could
> not
> > > go wrong before.
>


> > I'm sorry, but wouldn't that be very stupid of the client? Maybe the
> draft could
> > include wording that clients MUST NOT do that, to be extra clear, but
> IMHO it's
> > already quite clear.
>


> Of course, but isn't this issue that SCSV is trying to fix in the first
> place? Isn't the SCSV's reason of existance the fact that there are some
> buggy servers that cannot handle TLS protocol version negotiation? Why
> should we assume that buggy clients are impossible to happen?


It's not *completely* inconceivable that this could happen -- regardless of
which client or server behavior is newly introduced, there's always *some*
chance that it might not work well with some buggy peer.

When writing the TLS_FALLBACK_SCSV specification, I was thus aiming to keep
it simple enough so that implementors would be extremely unlikely to get it
wrong (at least once there's some base deployment of clients and servers so
that basic interoperability tests will immediately expose large classes of
potential bugs, which should by now be the case). Do you seriously think
that implementors might end up sending TLS_FALLBACK_SCVS unconditionally?
If so, do you think that those implementors would be capable of avoiding
other more subtle bugs, and overall to create a mostly usable and possibly
even reasonably secure product? (I can't help thinking that if a client is
*that* broken, we'd probably be doing its users a favor by having all
handshakes fail.)

More importantly, if there were no fallback retries and thus no need for
TLS_FALLBACK_SCSV, how could that *possibly* make it *easier* to deploy TLS
1.3 given that buggy peers may be around?

Bodo

v2.23.0 | Report a Bug | By Email