Re: [TLS] ETSI releases standards for enterprise security and data centre management

Daniel Kahn Gillmor <> Wed, 05 December 2018 04:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 247D5130DCC for <>; Tue, 4 Dec 2018 20:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L8cEgLmhrrkR for <>; Tue, 4 Dec 2018 20:07:45 -0800 (PST)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09F70130DCF for <>; Tue, 4 Dec 2018 20:07:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4E144F99D; Tue, 4 Dec 2018 23:07:42 -0500 (EST)
Received: by (Postfix, from userid 1000) id E8A0620581; Wed, 5 Dec 2018 07:07:33 +0300 (EAT)
From: Daniel Kahn Gillmor <>
To: Christian Huitema <>,
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 05 Dec 2018 07:07:30 +0300
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
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: Wed, 05 Dec 2018 04:07:47 -0000

On Sat 2018-12-01 10:02:44 -0800, Christian Huitema wrote:
> Which is indeed a huge problem. Security conscious implementations of
> TLS should detect the use of such "enhancements", and either abort the
> session or automatically treat it as insecure.

This certainly looks like a case of forum-shopping to do an end-run
around the underlying goals of TLS as a 2-party protocol that
prioritizes confidentiality, integrity, and authenticity between the two

Even worse, the supposed "VisibilityInformation" mechanism is stuffed
into subjectAltName in the server's certificate, which means that it
can't even depend on the "critical bit" that would have been available
to a standard X.509v3 certificate extension.  This appears to encourage
deployment to unaware clients.

I've just submitted draft-dkg-tls-reject-static-dh-00, which suggests
that responsible TLS clients that observe a server certificate with a
subjectAltName otherName with the VisibilityInformation type-id (OID {itu-t(0) identified-organization(4) etsi(0) msp(3523)
etls(3) visibility(1)}) MUST reject the certificate.  I'm open to
feedback on it.

One mitigating factor of the ETSI standard, i suppose, is that the
CABForum's Baseline Requirements forbid issuance of a certificate with
any subjectAltName other than dNSName or iPAddress, so otherName looks
like it must not be issued by standard public CAs.

top of p. 44 of

Has anyone set up tools to monitor the CT logs for such a sAN to see
whether that element of the BR is being honored?