Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients))

Peter Gutmann <> Sun, 24 May 2015 11:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB9D51A8A81 for <>; Sun, 24 May 2015 04:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6dgCQrEZyNos for <>; Sun, 24 May 2015 04:27:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35D3A1A8A80 for <>; Sun, 24 May 2015 04:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1432466868; x=1464002868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L5LfCAv2aIMCWjsvDAa+FUoe8PeM9DRHO+3Zi54uFZo=; b=4ddtN5EVoaSTTyocyArOhD/iPiVIyfQcXSf4Yfl5/88K0uFHCBwSBZa8 3QwCXexT0/6YihYY/zAF+SCVx2f8wwrUcU2NG4/ZGNHx2GrSkAludcdNk taXmTLulBAFqo6wDu401UU9U+t97VVU2d7m1f/QRe2yuaCz7vBmjp8EuF 4KfjaoZXkxKekU8GYv0sCrLLHr04sr+L/vgMrQAZcR3dwnHfoC0vsdw0Z eoIKzeHSg1rvwFQOj4rXPxQ5Lm26tQcd/ki8HW3X2f/NBQrrbBjUEmGfv 86+Rysr+oV0LbDPruZbcDma9660ZN5nkVVI5+PoTOkV35rtOJGe00eaL1 Q==;
X-IronPort-AV: E=Sophos;i="5.13,486,1427713200"; d="scan'208";a="17994047"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 24 May 2015 23:27:46 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sun, 24 May 2015 23:27:46 +1200
From: Peter Gutmann <>
To: Geoffrey Keating <>
Thread-Topic: prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients))
Thread-Index: AQHQlLPWR1x4OtJapki4aa+G2J1L4Z2K/VwA
Date: Sun, 24 May 2015 11:27:46 +0000
Message-ID: <>
References: <> <> <> <> <> <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl> <>, <m2d21szfwh.fsf@localhost.localdomain>
In-Reply-To: <m2d21szfwh.fsf@localhost.localdomain>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients))
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 May 2015 11:27:52 -0000

Geoffrey Keating <> writes:

>Telling people that these PLCs are secure and everything is fine and they
>don't need to worry won't fly either.  The owners of these devices are going
>to have to find a solution, whether it's an early hardware upgrade, 

Will never happen.

>firmware replacement, 

Typically can't be done.

>or a front-end translator/firewall.

As above.

For people who have never worked with these kinds of devices before, here's an

-- Snip --


SCADA devices often resort to all manner of exotic designs in order to provide
this high level of availability.  One such technique involves the use of
differential switching on all circuits, in which a value of |||false||| is
represented by a 0 signal on one line and a 1 on the other and a value of
|||true||| with signal values of 1 and 0.  If both lines are unpowered (due to
a loss of power) or powered (due to a short circuit) or the signal is present
statically (due to latch-up in a circuit) rather than dynamically (driven by a
clock pulse) then it's regarded as an error condition.

The clock pulse isn't necessarily a standard CPU clock but merely a
capacitively-coupled AC signal (so that applying standard DC power to the
circuit won't produce an output signal) that acts as an additional gating
signal that has to be present in order for things to work.  Even basic passive
components like resistors are mounted in such a way that they can't easily be
bypassed by a short circuit, for example by having the circuit traces that the
two ends of the resistor are soldered to on opposite sides of a double-sided
circuit board.

That's just the lowest level of the system.  Once you get above the basic
switching circuits you get into redundant buses, self-checking logic,
heterogeneous designs (for example an AND gate can be implemented as both |||a
AND b||| and |||NOT a OR NOT b|||, with the two circuits checking each other),
majority-logic decoding, and in general entire books full of exotic design
principles that would never be used in a standard system.

[Further discussion]

The overall rationale for not thinking too much about security is that there's
a higher risk created when a critical device isn't working due to a particular
security measure than through having some possible, often rather theoretical,
security flaw present.

-- Snip --

So when given a choice of availability/reliability over security, availability
wins every time (and quite rightly so).  The only time you can fiddle with it
once it's in place, ever, is when there's a clear and present issue that
affects availability.  "Race condition when reading vibration sensors is
causing the rotor-imbalance safety cutout to trip and take turbine #3 offline"
is a clear and present issue.  "Haxors might 0wn us" is not, so it'll be
addressed in the 2018-2023 product cycle.