Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

Hubert Kario <hkario@redhat.com> Thu, 02 June 2016 15:28 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B02912D769 for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.348
X-Spam-Level:
X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5hzo0UccE8hM for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:28:17 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82A712D76A for <tls@ietf.org>; Thu, 2 Jun 2016 08:28:17 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7DEB07F6A8; Thu, 2 Jun 2016 15:28:17 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52FSG8w003617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 11:28:17 -0400
From: Hubert Kario <hkario@redhat.com>
To: David Benjamin <davidben@chromium.org>
Date: Thu, 02 Jun 2016 17:28:15 +0200
Message-ID: <3427199.yLtZbr21AE@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.10-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <CAF8qwaASpH3Fapo61TDBuF35++GyMbZa4c-9Uy-JZ8CKywpAFw@mail.gmail.com>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <3713097.ExV049UdFl@pintsize.usersys.redhat.com> <CAF8qwaASpH3Fapo61TDBuF35++GyMbZa4c-9Uy-JZ8CKywpAFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1914464.UQ72xrpcKJ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 02 Jun 2016 15:28:17 +0000 (UTC)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/XI1VnIqCgzdNBRcXsgZduBLM4rg>
Cc: tls@ietf.org
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 02 Jun 2016 15:28:19 -0000

On Thursday 02 June 2016 15:07:53 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario <hkario@redhat.com> wrote:
> > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > > > <nmav@redhat.com> wrote:>
> > > > 
> > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> > > >> 2% is actually pretty good, but I agree that we're going to
> > > >> need
> > > >> fallback.
> > > > 
> > > > Please not. Lets let these fallbacks die. Not every client is a
> > > > browser. TLS 1.3 must be a protocol which doesn't require hacks
> > > > to
> > > > operate. CBC was removed, lets do the same for insecure
> > > > fallbacks.
> > > 
> > > Not every client is a browser, but some are. So what does the
> > > browser
> > > do when a server resets the connection after seeing the
> > > ClientHello?
> > > 
> > > Blank screen with a failure message?
> > 
> > fallback to check if the connection failure is caused by TLSv1.3,
> > and if it is, display error message and put the blame squarely on
> > the server
> We browser folk hate these fallbacks just enough as much as you do, if
> not more. I personally spent quite a lot of time and effort getting
> rid of it in Chrome (and I'm happy to say, as of Chrome 50, I seem to
> have succeeded). I'm sure my counterparts at Mozilla went through
> similar pains.
> 
> But reality is what it is. The Law of the Internet is the last thing
> that changed is blamed. We have a limited "budget" we can spend
> breaking things (otherwise I'd have removed almost everything by
> now!) and there is no chance I can break all the hosts I found.

that's why I said that the browser should diagnose the issue and put the 
blame where blame is due

user can't make an informed decision if he or she is not informed, 
printing "Alert: Fatal, invalid_parameter" or a "server aborted 
connection" is not information needed to make the decision

> I have been reaching out to figure out the broken vendors, but this is
> a slow process. It will not be flushed this out anytime soon. With
> TLS 1.3 as it stands, I think a browser fallback in the short to
> medium term is a certainty. (If your clients don't need it, then by
> all means don't add one! I envy you.)

for customers that need it, we explain the problem and provide option to 
override the maximum version supported to a lower one

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic