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

R duToit <> Wed, 05 December 2018 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71D06130E13 for <>; Wed, 5 Dec 2018 08:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RJwMQxAhvevd for <>; Wed, 5 Dec 2018 08:44:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BE3B128CE4 for <>; Wed, 5 Dec 2018 08:44:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1544028245; cv=none;; s=zohoarc; b=Zvfs1eQWVySJuooWPIo6a20P8MEGC5zwlD4+JxGRxL5VF+ioi6tff07yv3Mw8Vcd/4At4WWjCRKoWFtqRyIrtIfqIDobYfWF4VQHCEFu3ZpzaU/UrETy+NsIZrkwhldJ3p21hz2dp2MX9JbNcV+cxEdhxtM0vNI2DIGbT2M1/xc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1544028245; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=yMVuVGYREauHCsr1WiySkkn4YjoVccexTL4cEAvJSl0=; b=bp13ijaLxjnQPfm0JTgrV+S1MRZ69GZCm2I5U4dFoVkYnogqU1sPMhaVqlE4SjPFZhJknR+udTWoJQSlWCStv5yWlix2zYWzIFbjjs3M+vYbiuSEU5CoThhusC8E1kZbjrx6OvuusJj475X2/5RDvA98efWY0UN6AQdhLDehgfA=
ARC-Authentication-Results: i=1;; dkim=pass; spf=pass; dmarc=pass header.from=<> header.from=<>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1544028245; s=zoho;;; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=7870; bh=yMVuVGYREauHCsr1WiySkkn4YjoVccexTL4cEAvJSl0=; b=KAKIkTRkJzb6XtWmTJnVQA16pBBBtcPNlBXz/XN9H4IyQSdS/lU7fupEyhSocMhN 2ueLsxOZBZOcIlnRQgVBJD6/VtAf4ETfFuz0BLGAd4/mEwMKGXkkUfWPwz2slgR5+LH PJJ8l41HBw7eJkoe/drUfYYngaFAz3PuhH5ti/EY=
Received: from by with SMTP id 1544028244400541.7880402496648; Wed, 5 Dec 2018 08:44:04 -0800 (PST)
Date: Wed, 05 Dec 2018 11:44:04 -0500
From: R duToit <>
To: "Tony Arcieri" <>, "<>" <>
Message-Id: <>
In-Reply-To: <>
References: <> <> <20181202233553.GD15561@localhost> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_924041_489574463.1544028244398"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
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 16:44:13 -0000

I like the gist of what Tony is saying.  Key escrow (it should be called "secret escrow", but I digress) itself is not really the problem in a datacenter - those guys struggle to solve the key distribution problem.  If it was one-server-to-one-tool then we would not be having this discussion.  eTLS looks like an attempt to simplify the key distribution implementation, but at the expense of the security attributes of the TLS session. Why don't we provide a "sandbox" mechanism that would allow business-solution folks to solve the key distribution problem without directly affecting the TLS session?  What I have in mind is a TLS extension that would unlock a new TLS record ContentType called "foo" (for lack of a name).  All "foo" records will be completely ignored by the TLS stack, including not affecting the TLS record sequence number or crypto state.  That mechanism can then be used to send in-band messages that could be picked up by inline and passive tools along the way.  Mechanisms that use "foo" records could potentially be designed outside the IETF, and the TLS-WG would have no responsibility for insecure implementations of multi-party secret sharing mechanisms (although it would be good to point those engineers in the right direction). --Roelof ---- On Wed, 05 Dec 2018 10:51:26 -0500 Tony Arcieri <>; wrote ---- On Wed, Dec 5, 2018 at 12:09 AM 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 IETF. [...] On Dec 5, 2018, at 1:18 AM, Tony Arcieri <>; wrote: [...] It seems like with an out-of-band escrow agent, the traffic secrets could be escrowed with no changes to TLS. Note that the solution I was proposing here requires no changes to TLS. I am sure that there are many in the IETF who would be happy with people exploring solutions which don't require changes to TLS. Here are some others: Endpoint agents (OSS - commercial options are also available): (now Zeek) Encrypted traffic analytics: -- Tony Arcieri _______________________________________________ TLS mailing list