Re: [TLS] Broken browser behaviour with SCADA TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 04 July 2018 07:57 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 D2B35130DF9 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 00:57:45 -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 zlgHZlI_T6Yc for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 00:57:44 -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 3850D130DC1 for <tls@ietf.org>; Wed, 4 Jul 2018 00:57:44 -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=1530691064; x=1562227064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=booJYq1fNY16ggp/2EzRLAMRO2LvxeNokz6ouRRO7jo=; b=lA1kgohnS5n6Z9KEh6jPQ+g/0LUk+ec1sIYkZ8Zj4gD2Q+8bHFm8gUFC 9SgZN3huEWjDkV2S7XSTYOcMLSGSjOX6r2HpMppNB1z/ZcS0JzLQrwZVt tdqvyHJ/3ql9psbuBasYBUijlxnDP4oaTP5cZhc138vO4FKIEuuSUIpMS 4oZCQBKJTNQODrgNR3MdVxGS9307OwX+YyFPOK5MMfwRGBeDn1dlZc17Z sS38sayNzq6Ny/PR3S9xO/TeNFTMWwPUp/8oaOc3BwUQZtfX5saumGdvA J6E8mXJdepBHN6qS4kD1CrTieYVcEwXvXioVjTEbZlP/YJlcSw2HlE0Kg g==;
X-IronPort-AV: E=Sophos;i="5.51,306,1526299200"; d="scan'208";a="19536371"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Jul 2018 19:57:42 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.29) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Jul 2018 19:57:41 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Wed, 4 Jul 2018 19:57:41 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS
Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYg==
Date: Wed, 4 Jul 2018 07:57:41 +0000
Message-ID: <1530691044974.54956@cs.auckland.ac.nz>
References: <1530687136897.97792@cs.auckland.ac.nz> <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com>, <20180704074101.GA19789@LK-Perkele-VII>
In-Reply-To: <20180704074101.GA19789@LK-Perkele-VII>
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/m4TD0UAZYylrRA2oOA35_qGs2Uw>
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 07:57:47 -0000

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?

>- AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with
>  RSA or DSS certificate (good luck getting DSS certificate, and even
>  more luck getting clients to accept it).
>- AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only
>  RSA certificates are supported.
>- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are
>  supported.

Wouldn't matter much anyway, suport for those is practically nonexistent (CCM,
Aria, Camellia, ChaCha20, and so on, I mean).

OK, "practically nonexistent" may be too optimistic, I've never heard of
anything supporting those.  Having said that I don't know of every SCADA
device in existence, maybe some Korean devices somewhere do Aria.

DSA certs aren't a problem since they're all from non-commercial CAs (in-house
or self-signed), but I only know of a few systems using DSA.  Can't remember
why they did that... oh yes, because keygen was faster/more efficient for DSA,
just a single modexp and no requirement for lots of CPU and memory.

Peter.