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

Daniel Kahn Gillmor <> Wed, 05 December 2018 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30967130DE3 for <>; Wed, 5 Dec 2018 01:31:01 -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 idjRnLRgSM6J for <>; Wed, 5 Dec 2018 01:30:59 -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 4FDE3130DE5 for <>; Wed, 5 Dec 2018 01:30:58 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 233BDF99A; Wed, 5 Dec 2018 04:30:57 -0500 (EST)
Received: by (Postfix, from userid 1000) id 5212B202FC; Wed, 5 Dec 2018 11:27:33 +0300 (EAT)
From: Daniel Kahn Gillmor <>
To: Bret Jordan <>, Tony Arcieri <>
Cc: Crypto <>, "\<tls\\>" <>
In-Reply-To: <>
References: <> <> <20181202233553.GD15561@localhost> <> <>
Date: Wed, 05 Dec 2018 11:27: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 09:31:01 -0000

On Wed 2018-12-05 17:08:44 +0900, Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real
> problem and need.  We can either address the use case and need here in
> the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this work item back and solve it here in the

Or, the IETF can say with relative clarity that this kind of information
leakage is inappropriate for and incomaptible with the information
security goals of TLS.

> Finally, remember, you may not like the use case or need, but that
> does not mean the use case is not valid and needed.

Sure, but just because someone says it is, doesn't mean that the use
case is valid or needed within the scope of TLS either.

Throughout the (several years now) discussion of this sort of proposal,
we've repeatedly heard about "legal obligations" which somehow evaporate
when pressed for details.  And we've heard about "operational
considerations" which typically amount to cost-shifting concerns (they
can come across as: "we've invested a bunch of money in this particular
network architecture/application design, please change the infosec
guarantees provided by TLS for everyone on the global network so that we
don't have to do an expensive re-tooling or staff up on new skills while
i'm responsible for this budget line item").

The WG is chartered to make TLS a fast, secure, confidential transport
layer.  Let's keep the charter goals in mind.