Re: [TLS] Broken browser behaviour with SCADA TLS

David Benjamin <davidben@chromium.org> Wed, 04 July 2018 15:16 UTC

Return-Path: <davidben@google.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 AB586130E10 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 08:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Level:
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 97EysSvegwUX for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 08:15:59 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB61130E7C for <tls@ietf.org>; Wed, 4 Jul 2018 08:15:58 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id o2-v6so3005028qkc.13 for <tls@ietf.org>; Wed, 04 Jul 2018 08:15:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lvcQJQUaX1WlPrmTjPH7IEtashdXUwMp1Oqku7v55LA=; b=ZYO+Mg5FCYVUBG1XkPV4cvmVa9WCX8E6IYH7B626cOSROpjC/VjShiHaN27si0bNie 4FNcG5QQxM7B8L0FOUgv6Op5w5J8M5u4b8jQexmaZGFWN5S2GJwiqaM6+9sQ7H23SmwQ d3WaQ75KSJEBc9By38BLck1mP07+gvgjwdbpI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lvcQJQUaX1WlPrmTjPH7IEtashdXUwMp1Oqku7v55LA=; b=P+TmnyC5P5B4AHgLHWa4mwvzU79SVId7IVwtjmk05tP1JoE6IHfg/PzJPEqdDyuLzK +UprGhYK59HWAiaLiHQsvgKPj7ZunlF2oSsPcAodUB3b0B3cyMLHrwAFQtCY+pGaM8YP 1CYd7zQAoYOdq8QxGJisdnsmUa/m8UpCgB6OflKnToRLkoPsVW2QmXyugcEHLuf09e0m HjVQrbU4+YheKA8a4ynsvHyk6iaQCGRrHtzsOgPSHVB9fduMhha3GpxY4qqBhG1F+MGy evVwXR4uKX4ixzQIauSqnc+fn1odzhk5JinGt25X3jwxMtslYwE7bVXhewRRlIjlXaZm 3nLQ==
X-Gm-Message-State: APt69E29FEzEKfhCCd54Th7yGGfnoCa8cKssWIatlixU1wzNaDCUPgna gD9flv4iwQJlqiwNJipZo4JuLCCo3vg2veaK9vHk
X-Google-Smtp-Source: AAOMgpccJpAlyA7Z5jdJMl4v3iMeozWi4gDyxtDs9kjc4Cozmsc0wU+dQo2Z4z9hGuYEPHVlEtjMN6GT0g5CiDv/KUM=
X-Received: by 2002:a37:7d87:: with SMTP id y129-v6mr1930919qkc.232.1530717357589; Wed, 04 Jul 2018 08:15:57 -0700 (PDT)
MIME-Version: 1.0
References: <1530687136897.97792@cs.auckland.ac.nz> <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <b8ecb2cfdac0495f188baf9df187c075e70c3a58.camel@redhat.com>
In-Reply-To: <b8ecb2cfdac0495f188baf9df187c075e70c3a58.camel@redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 04 Jul 2018 11:15:45 -0400
Message-ID: <CAF8qwaBTHfn7iBEaZ9QQ2ueP09Qn4J2s1sBWhqopTzq7eLF6ww@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005a679e05702de887"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-DG5EmYu9KNH1lhfSNceGKpTNSM>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 15:16:02 -0000

On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos <nmav@redhat.com>
wrote:

> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
> > On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote:
> > > Ilari Liusvaara <ilariliusvaara@welho.com> writes:
> > >
> > > > More serious problem is servers returning too small modulus due
> > > > lack of
> > > > negotiation. Which was the reason why Chrome disabled DHE.
> > >
> > > Why not reject the handshake if the modulus is too small, rather
> > > than
> > > disabling all DHE suites on the off chance that the server returns
> > > a value you
> > > don't like?
> >
> > Chrome initially did that. It caused quite a lot of bad feedback from
> > owners of various bad embedded stuff. The thread on relevant forums
> > was
> > quite something. Hundreds of messages blaming Google for breaking
> > stuff.
>
> We had similar experience when we required a minimum of 2048-bit
> modulus for all TLS connections in Fedora 28 beta irrespective of back-
> end lib. It broke connections to VPN servers and web internal web sites
> and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
> doomed and rfc7919 couldn't save them.
>

Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere
1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we
encountered a lot of this.) 2048-bit was completely hopeless. At the time
of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum.
See here for details:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ

I should add to that link that the "draft specification which fixes the
negotiation problems", now rfc7919, did not fix the problem. This was
pointed out here, but never incorporated to the document:
https://www.ietf.org/mail-archive/web/tls/current/msg18697.html

To the original email, it seems the second and third scenarios are
identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA
server key. The third and fourth scenarios are indeed unsurprising for a
browser that doesn't support DHE. You should instruct these folks to
configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the
second scenario, it seems they're already implemented, just the server was
incorrectly configured to use the wrong ones.

DHE at acceptable sizes is quite slow anyway, so their servers may well
appreciate the speed boost. (Indeed, I often see DHE disabled in server
deployments as otherwise the poor servers would melt.)