Re: [TLS] draft-dkg-tls-reject-static-dh

Peter Gutmann <> Sat, 08 December 2018 05:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F540131113 for <>; Fri, 7 Dec 2018 21:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 DxWtBQTah--r for <>; Fri, 7 Dec 2018 21:21:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EE1912D4ED for <>; Fri, 7 Dec 2018 21:21:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1544246501; x=1575782501; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=avghPUGLQ7OYZfczUseU5Tb7SGGSP4ODUG+x1+zddaA=; b=L1wFNm+JgJ8irTdGEYck7XI7yGgU7wweDOKcRnpxASbSYgnHI7dmYmoJ Vu968wO084mN8s6kx/rPobmCixJPeF+X++hbBQ6vIYy/Fby8//dt/e2UX JYJSuR4py8VFdEpx4O0uoLTSsLw+xY00n6KGic+07smdkzb5TGv5/djsg v3mR5yrSG/pYsmUxS6FoCfwkkP4LW1VsXpPh2L+kF9pqPJDv6tdjuCbmp fkkiHdohG1R2SmRNDnBJnZkj6l+bBwhPcv3SKY5DU1sdcvjoAGN2ZQvQ9 jRCUslfcAAeOX5+s9sDEvAXCt+aJpp7K3yzmUveR/y4LG1StM34MzPwFH Q==;
X-IronPort-AV: E=Sophos;i="5.56,329,1539601200"; d="scan'208";a="42408027"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 08 Dec 2018 18:21:36 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 8 Dec 2018 18:21:35 +1300
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Sat, 8 Dec 2018 18:21:36 +1300
From: Peter Gutmann <>
To: Daniel Kahn Gillmor <>, Nico Williams <>
CC: Stephen Farrell <>, "" <>
Thread-Topic: [TLS] draft-dkg-tls-reject-static-dh
Thread-Index: AQHUjMy2+Ip4vOdFW02pqhJ3jndT6qVxloSAgAE690z//yyCgIAA4O8ngAB4LYCAAPr7AA==
Date: Sat, 8 Dec 2018 05:21:35 +0000
Message-ID: <>
References: <> <> <> <20181207064745.GU15561@localhost> <>,<>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [TLS] draft-dkg-tls-reject-static-dh
X-Mailman-Version: 2.1.29
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: Sat, 08 Dec 2018 05:21:45 -0000

Daniel Kahn Gillmor <> writes:

>> [0] "In principal" because there's a fair bit of SCADA gear that does this
>>     because it doesn't have the CPU power to generate new DHE values, as I 
>>     found out when I turned on non-DHE checking some years ago.
>Is this SCADA gear running TLS 1.3?  is it clients and servers both, or just
>one or the other?  When was this scan done?  i'd love to see more
>documentation about this practice.

No, it'd be mostly 1.0, moving slowly to 1.2 at some stage (I spend a fair
chunk of yesterday debugging a handshake failure that turned out to be the
fact that the current, most-recent release of the code in a fairly significant
code base can't understand anything newer than TLS 1.0).  It wasn't a rigorous
scan, it just got enabled for a new release and then there were enough
complaints about it breaking things that it got removed again.

I don't really know if it's possible to do any kind of useful survey of the
SCADA environment because most of it is invisible to the public internet, you
just try various things on a small basis and if no-one complains, push it out
to more and more users and hope you don't get complaints.  Sometimes things
break, for example within the last month we had a customer who thought "USA"
was a valid ISO 3166 country code:

231  12:       SET {
233  10:         SEQUENCE {
235   3:           OBJECT IDENTIFIER countryName (2 5 4 6)
240   3:           PrintableString 'USA'
       :           }
       :         }

Since no-one seems to check whether the C= component in a DN is a valid
country or even looks like a valid C= component, it hadn't been noticed
before.  No idea what would have ended up in there if they were in Saint
Vincent and the Grenadines or the Federated States of Micronesia.

Anyway, I don't have any real data, just that it was common enough that we had
to remove the check again.  When I talk about SCADA stuff and it sounds rather
anecdotal that's because it usually is, you enable a new feature and if you
don't get complaints, leave it enabled, but that's as far as it goes in terms
of coverage.