Re: [TLS] Inclusion of OCB mode in TLS 1.3

Peter Gutmann <> Sun, 25 January 2015 04:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B76521A1EF1 for <>; Sat, 24 Jan 2015 20:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tEfyMuP93EhR for <>; Sat, 24 Jan 2015 20:05:11 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3177C1A1EEF for <>; Sat, 24 Jan 2015 20:05:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1422158711; x=1453694711; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=5rWgYYU6AHK1hu4019Q28TTTD3hRj43nMsk06EKHVXM=; b=oYH5mQL2U8Z86SB4GHLbdDmnuP8d5V+IsAeVz5r82dLZcTCfqj9hxYDl qwUonDAiRw72GdtXsJTdxshoCWJxFqp3Xrpen4zfeeoJeWkXE7WppYev+ cyHAPmkC7GOPl4vP1U8KPwnhtg18jKriQmTmd88os82sOmWNZ0Fsnny3S 4=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303475077"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 25 Jan 2015 17:05:10 +1300
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sun, 25 Jan 2015 17:05:09 +1300
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] Inclusion of OCB mode in TLS 1.3
Thread-Index: AdA4VBwK0FPWNrzkQM+LIdaA1EalXg==
Date: Sun, 25 Jan 2015 04:05:09 +0000
Message-ID: <>
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: <>
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
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, 25 Jan 2015 04:05:12 -0000

Aaron Zauner <> writes:

>That's a nice trick but as you point out pretty useless in terms of a PKI.

It's done solely to deal with browsers, which demand to see a certificate when
they're connecting to something via TLS.

(Aside: You can see why some people think the CA/Browser forum as a conspiracy
 to force the use of certs, despite there being very good alternatives
 available browsers force you to use certificates whether they're appropriate
 or not).

More generally, PKI is pretty much useless for many SCADA situations.  Take
for example IEDs, the unfortunately-named Intelligent Electronic Devices used
in the power industry.  These talk something like GOOSE/GSSE or MMS running
over DNP3 or switched Ethernet, or maybe Modbus, for which PKI makes no sense
whatsoever (both because the way things are identified don't work with
certificates, and because the concept of doing cert-provisioning and
revocation checking and whatnot in an IED like an on-load tap changer
controller is just bizarre).

What I've seen so far (and things are in a state of change at the moment
because there are standards that say you have to use TLS with certificates and
whatnot and the industry is realising that while it's fine to say that in a
spec, it doesn't work in practice) is a management interface using hardwired
certs (the memcpy()-a-blob system) and then the control interfaces using PSK
or who knows what else (there are vast numbers of protocols used, it's a
headache to untangle them).