Re: [TLS] Broken browser behaviour with SCADA TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 10 July 2018 13:27 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 93D95130E78 for <tls@ietfa.amsl.com>; Tue, 10 Jul 2018 06:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 ra5XptyBeWkh for <tls@ietfa.amsl.com>; Tue, 10 Jul 2018 06:27:47 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2849D130E9F for <tls@ietf.org>; Tue, 10 Jul 2018 06:27:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531229266; x=1562765266; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lxlbLXQraw6C66VaGbkHLSiKyZZE85W8+gWgY0Y9gnE=; b=zNpWPKaQE4Kz4cdvO0Q8qmK1tc9/dX8UTWVOJYuPpNyxm+jzkPQD3pM/ vVj97qaGKGSozDRwEAoWRNH4DrAuwYCUebBRXLJDXbTjyHmV4WewDAGlg x53LylQk+M0hyNptakMekiRQy2qRBv0B+YkCS6ahommmU0UwBu7+wCZ8i Sy1RZprzppLxJB9IclTSRV0NG1Z9qrXSWdgxAKJxVlF9yxI7zJzvoFZXk Me1k/zS4SwhpaZhElsmK058ek93VBMN2PAtaXE4Wcy3TcIhFSUh6PEXGI QChMA+t6mjx3ALVbZP6GCsQBmqzpmgkmBhOKZ48DMfhF2pm5LQohxqhcg A==;
X-IronPort-AV: E=Sophos;i="5.51,334,1526299200"; d="scan'208";a="20546415"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing
Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2018 01:27:41 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Jul 2018 01:27:40 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 11 Jul 2018 01:27:40 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: =?iso-8859-1?Q?Bj=F6rn_Haase?= <bjoern.haase@conducta.endress.com>, "Hubert Kario" <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS
Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAAHUoCAAG4mgIABhdIIgAYN+oCAAawvkP//n++AgAE4ogk=
Date: Tue, 10 Jul 2018 13:27:40 +0000
Message-ID: <1531229231537.52372@cs.auckland.ac.nz>
References: <1530687136897.97792@cs.auckland.ac.nz> <CAF8qwaBTHfn7iBEaZ9QQ2ueP09Qn4J2s1sBWhqopTzq7eLF6ww@mail.gmail.com> <1530757910178.45400@cs.auckland.ac.nz>, <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> <1531182771058.21025@cs.auckland.ac.nz>, <VI1PR0502MB396829B25B25170E6BC78129A85B0@VI1PR0502MB3968.eurprd05.prod.outlook.com>
In-Reply-To: <VI1PR0502MB396829B25B25170E6BC78129A85B0@VI1PR0502MB3968.eurprd05.prod.outlook.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q11D9pX95khZvSSeaqJJys_9Uu0>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 13:27:51 -0000

Björn Haase <bjoern.haase@conducta.endress.com>; writes:

>BTW, This is actually why we in the ICS business need TLS1.3 with its fast
>options on tiny devices such as X25519 and Ed25519. That's by integer factors
>faster on devices such as the M0 or the MSP430 than all of the fastest legacy
>options, such as P256!

How are you going to get TLS running on an MSP430 or even an M0?  You can
barely do anything on an MSP430 (it's enough of a challenge getting a TCP/IP
stack going on that, uIP is a rather clever piece of programming but beyond
that you can barely serve web pages from it), and an M0 isn't much better.

See specifically p.12 of
https://www.cs.auckland.ac.nz/~pgut001/pubs/problems.pdf for the MSP430 (those
slides predate this thread by a number of years, so it's not something I've
set up just for this thread).

I would actually love to see a TLS 1.3 implementation on an MSP430.  As far as
I know it's physically impossible, but if someone did it it'd be both
fascinating and horrifying to see what they had to do to make it work.

In any case it's not the crypto that's the problem, the biggest code and
memory issues are, in order:

1. Certificates.
2. The TLS protocol.
3. The crypto.

where (1) >> (2) >> (3).  That's why I mentioned in a previous message
implementations that use memcpy() for their cert management, which eliminates
(1).  To process the cert / cert chain, you scan the network read buffer for
the string "\x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x01" and copy out the two
integers that follow, so your cert processing is reduced to a few pages of
code (the thinking behind this is explained on p.23 of the same slide set).

Then you've got (2), which has been getting more and more problematic with
each rev of the spec as more and more options get added with each new rev.
Luckily you can fast-path the single option you want to support, for example
for TLS 1.2 with DHE+RSA you don't need extensions, and if you can do ECC and
see an ECC suite in the client hello then you ignore the incoming TLS
extensions and write back a fixed blob specifying -256 for everything (P256,
SHA256, etc), uncompressed points, and so on.  Another thread mentioned that
you can't do TLS 1.2 without extensions, when in fact you can, you just rely
on the fact that everything supports -256 by default.  (This is also why -LTS
makes the -256 otions a MTI, it's the de facto default anyway).

This is where 1.3 is a problem, not a feature.  It's now got so much MTI
complexity, most of which is completely unnecessary for SCADA, that any minor
gain you might make in the crypto implementation is completely lost in the TLS
protocol implementation overhead.

I don't know how vendors are going to deal with this.  There'll be some tricks
used, like the TLS 1.2 "extension handling", but I don't know about the rest.
My guess is they'll stay with 1.2, in the same way that they're staying with
HTTP 1.1 when 2.0 exhibited the same problems.

Having said that: "Predictions are always difficult to make, especially about
the future".

Peter.