Re: [TLS] Broken browser behaviour with SCADA TLS

Martin Thomson <> Wed, 04 July 2018 09:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1C2A130E48 for <>; Wed, 4 Jul 2018 02:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6iG83x7uwM_h for <>; Wed, 4 Jul 2018 02:22:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9278130E42 for <>; Wed, 4 Jul 2018 02:22:45 -0700 (PDT)
Received: by with SMTP id c6-v6so9501573oiy.0 for <>; Wed, 04 Jul 2018 02:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yYRZsQEI5ZyXnBjSVQ1DJa0vy9QNGH3ZD2SCkpPhL/Y=; b=oLBVauFZ+zJIJtFYKajrR7eN64YPwRgBdaNL6kUwWVSjYfmwZBk+kZORTx9DNfWZK+ koMQG4mCKG0cnGkbR5TpEVADT2H20vVrAyNyJxZIbGpVqbqVO98hUcsvDCv/Cd2jWTV0 W2Ur5F3/UByctEiQqdx2C22uGQOfIixf7kigzK8mjlzGIOxmBcpaAGWpQX43vMmK6/eG CsCOT00b+Szu2mvnbbNovGAQFbWbeaWSmH7fcl3nGs2Gu+PE1afaSuTZk8D+KubuD3jV yAjAVJNR5ymlCnZeKD0saSZUH2LbXjm3yC5Momg/zXmfLbbnP6OpKl0Ylk+pvnKEIsdu irjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yYRZsQEI5ZyXnBjSVQ1DJa0vy9QNGH3ZD2SCkpPhL/Y=; b=EHJtjWJCP7vl4IPwdhIP9TLChNkG8JCcN5GGoVzRp/wWYG03SvsXWmHjOUQreBxvrI MjY27ersGOR83eqmpYfXJK4bAGrKb2K12vCCw/XnPeBkUgosMAtESH0C1+WUzZVqVQsT XuHJShFPFQmRplQa51R1Fz5Abdg6ZeGyPvcK2OsCJDF2Ok3ZRMgPwaE+jaaIKjmYu923 953qu8aevdeZHsSRnRgtQsgncRhUMhU7pAv4zA5vd/3AvLAqdUmuBL3MaUV1z9AWkx+a ok9NEiLqeRHKAhLQ4yYNqWBO/q0E9kTBavRgO3C5W2SiK9SGUvFG1E8BjUL1G2Nw/10g XMDw==
X-Gm-Message-State: APt69E2j9sP+/jqPaKsZEebGO+lDzwlNOR4GLZDfOQZNdgtqZcJubkjJ lPZuT4gTOATe53LYTzcuVhgfaNLI4zvKxLR34/I=
X-Google-Smtp-Source: AAOMgpcPB5E4buelyONiFQbzBXzJK8Bzn8v2hUyfx9Yak6D3GEokrRP2HS1hW/WCna6+QUFt7YHNvaMawJdJJF/PSxI=
X-Received: by 2002:aca:745:: with SMTP id 66-v6mr1197299oih.295.1530696164890; Wed, 04 Jul 2018 02:22:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <20180704074101.GA19789@LK-Perkele-VII> <> <20180704081519.GA20000@LK-Perkele-VII> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Wed, 4 Jul 2018 19:22:33 +1000
Message-ID: <>
To: Nikos Mavrogiannopoulos <>
Cc: Ilari Liusvaara <>, Peter Gutmann <>, "<>" <>
Content-Type: multipart/alternative; boundary="0000000000002adbd9057028f928"
Archived-At: <>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Jul 2018 09:22:48 -0000

On Wed, 4 Jul. 2018, 18:42 Nikos Mavrogiannopoulos, <>

> 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.

It has been suggested that 7919 makes things worse.

We have minimum modulus size constraints and haven't had any reports of
issues, but the limits are fairly low and we have a less diverse usage
environment than Redhat.

We're also unable to catch big values that aren't prime, or values with
small subgroups. We end up trusting servers more than we might consider ok
for a modern protocol. That isn't a massive problem in my view.

Of course, our recommendations don't change. Right now, that is to use TLS
1.3, or at least the configuration of TLS 1.2 that most closely resembles
1.3. The rest is stuff we merely tolerate for the sake of interoperability.
Soon, I hope, we might be able to get rid of TLS 1.0 and 1.1, and these
questions will be somewhat less interesting.