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

Hubert Kario <hkario@redhat.com> Thu, 16 October 2014 14:28 UTC

Return-Path: <hkario@redhat.com>
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 2A66C1A1A6C for <tls@ietfa.amsl.com>; Thu, 16 Oct 2014 07:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level:
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 TLfFtNCSL3xr for <tls@ietfa.amsl.com>; Thu, 16 Oct 2014 07:28:29 -0700 (PDT)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293881A1A28 for <tls@ietf.org>; Thu, 16 Oct 2014 07:28:29 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s9GESPMZ005685; Thu, 16 Oct 2014 10:28:25 -0400
Date: Thu, 16 Oct 2014 10:28:25 -0400
From: Hubert Kario <hkario@redhat.com>
To: Manuel Pégourié-Gonnard <mpg@polarssl.org>
Message-ID: <50007956.12601054.1413469705233.JavaMail.zimbra@redhat.com>
In-Reply-To: <543FCC90.7020408@polarssl.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: UzFvmGXgfeJ+fD1OR7x9fukXA9suEw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Ry3bFdYxrjZIt9VWRbO6beEidQ
Cc: Florian Weimer <fweimer@redhat.com>, tls@ietf.org
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:28:31 -0000

----- Original Message -----
> From: "Manuel Pégourié-Gonnard" <mpg@polarssl.org>
> To: "Florian Weimer" <fweimer@redhat.com>, "Martin Thomson" <martin.thomson@gmail.com>, "Bodo Moeller"
> <bmoeller@acm.org>
> Cc: tls@ietf.org
> Sent: Thursday, 16 October, 2014 3:48:00 PM
> Subject: Re: [TLS] Working Group Last Call for	draft-ietf-tls-downgrade-scsv-00
> 
> On 16/10/2014 15:41, Florian Weimer wrote:
> > On 10/16/2014 12:40 PM, Manuel Pégourié-Gonnard wrote:
> >> On 16/10/2014 12:06, Florian Weimer wrote:
> >>> Interesting things will start to happen once there is TLS 1.3.
> >>> TLS_FALLBACK_SCSV could really complicate its deployment.
> >>>
> >> I'm afraid I don't understand which interesting things you're referring
> >> to.
> >> Could you please elaborate on that?
> >>
> > 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.
> 
> Besides clients doing this stupid thing, do you see other bad things related
> to
> FALLBACK_SCSV that could happen when TLS 1.3 will start being deployed?

I don't see any.

Both NSS and OpenSSL when they receive TLS1.2 client hello with this SCSV
accept and continue connection.

Both NSS and OpenSSL when they are limited by configuration to a lower protocol
version (e.g. TLS1.0) and receive Client Hello with the same or higher version
and this SCSV accept the connection.

In other words. If, for any reason, a future client (one that supports TLS1.3)
decides that it needs to downgrade the connection (and indicate that by adding
the SCSV) to interoperate with current implementations, it will work correctly.

Of course, if a client sets this SCSV always, even on first connection attempt,
then it will fail after the server upgrades to TLS1.3, or it uses the library
that doesn't support higher protocol versions (like 0.9.8), but that's
incorrect use of the SCSV.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic