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

Bret Jordan <> Wed, 05 December 2018 10:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EF0C130DDF for <>; Wed, 5 Dec 2018 02:22:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MvFD04S0VITH for <>; Wed, 5 Dec 2018 02:22:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75CD4130DCC for <>; Wed, 5 Dec 2018 02:22:26 -0800 (PST)
Received: by with SMTP id z23so9856935plo.0 for <>; Wed, 05 Dec 2018 02:22:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EDx/s0jmVXVBZM8cT4K1ROqcWnyrNVofKwR5eSiFS6E=; b=Zfs8xabl71CguWvkJL5AjOOtjTvNpyW8z0xnubUK3/6J1eglY5HXYZx8TmMxfAoIA4 lHayO/TwMJLwaPhaTHNaOC0hx/UAUOh6sls4nCauOsxlR9Kdi0nLn60pKg8ag6kOK4Pu uJD16oi4aWKFDhUrgTBIYYFmJ64gMMGkgnntFJePxldmpdDO5tJYwYzc2fxAjXQk07cD Jn7aDKXfg0snfco3674tQ30jpBLE2P8gaOmA+V7QnOA+fKffnktE9XYhwZUtabXLqm2k 6hyj+weAiXdYgFbXQcrV59Q0se0kctgMt5QtumYonhEttT3pWG/GRpnuvtLRopksSAUE UF2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EDx/s0jmVXVBZM8cT4K1ROqcWnyrNVofKwR5eSiFS6E=; b=fZENUNmWbODoAFiBO5AOmUDWDcncdU143iwWG077k/z2SlJ3F18YHTTAjlD5jXeRxc iHhtFaCUEqectq6Bzcrh8a0bvLzD8fwER3B0PTfRn4Jg9rEePqjqZhKthqisg4HT8SA9 SyuayCwn5bmmdz1LWbr5atS+zDEdnBnW4SLm/ftJ1IzyVYeCXci3VZcqWpPtpclb5h7r vJAMNzsQlyQNoeSVF1aTJNuv70H3Cog0jn5nnweB7rYuV06M+Ur4HA+/tuXKGpsx/pwv bX0A6qLz7qxD1Um0mgjr+vbDjsP2oF6JSZy+iG+eugGq63VPD5q2AMUCK3XyX8n0h9Hw wKzw==
X-Gm-Message-State: AA+aEWYeKLfc0eelyPqmFnsbefwKn29gGjrojaYppmXEg6qP6ZkmKgfr dE6Gm+nc4+eZktGFDZk+HzU=
X-Google-Smtp-Source: AFSGD/WTKDYl5wjZFOZcCaNX9ixolom0gbyHomXzra4gX7sMejubMyObFSjpz0x3YD/4rAuByea0cQ==
X-Received: by 2002:a17:902:1745:: with SMTP id i63mr23056023pli.145.1544005345993; Wed, 05 Dec 2018 02:22:25 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y71sm33479288pfi.123.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 02:22:25 -0800 (PST)
From: Bret Jordan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_75065099-5058-4BD3-A94F-F77271EAF533"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 5 Dec 2018 19:22:05 +0900
In-Reply-To: <>
Cc: "<>" <>
To: Stephen Farrell <>
References: <> <> <20181202233553.GD15561@localhost> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
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 10:22:28 -0000

I think we should be more open minded and look at the needs from a 360 degree deployment perspective. The real power of the IETF is in looking at all the needs and requirements and designing solutions for them.

We should flesh this out. It seems like several people on this list so far have proposed options that might work. If we spent half as much time looking for a solution as we have trying to prevent a solution, we would probably be done by now. 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Dec 5, 2018, at 6:12 PM, Stephen Farrell <>; wrote:
> On 05/12/2018 08:08, 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.
> #include <previous-discussions>
> I would hope the WG not revisit this topic and see no new
> facts to justify distracting the WG again. Forum shopping
> is not new - rubber-stamping by ETSI or ANSI was explicitly
> proposed as a putative reason to adopt draft-green and that
> did not result in consensus to work on this topic despite
> the significant effort put in by proponents. I'm also happy
> to say that I see no evidence that the WG would reach a
> different conclusion as to lack of consensus.
> FWIW, I view this discussion as being analogous to scratching
> an itchy scab - despite our knowing it is unproductive to do
> so, some IETF participants apparently can't resist poking at
> the wound:-(
> S.
>> Finally, remember, you may not like the use case or need, but that
>> does not mean the use case is not valid and needed.
>> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
>> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
>> the only thing that can not be unscrambled is an egg."
>>> On Dec 5, 2018, at 1:18 AM, Tony Arcieri <>;
>>> wrote:
>>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams <
>>> <>> wrote:
>>>> I'm not a fan of systems like this, but I believe for security
>>>> reasons they should be designed in such a way that only the
>>>> confidentiality of traffic is impacted, and a "visibility" system
>>>> isn't able to leverage the decrypted traffic to resume decrypted
>>>> sessions and thereby impersonate clients.
>>> Any key escrow system will have this property.  Given the session
>>> keys (or a way to recover them) you can resume decrypted sessions.
>>> Wouldn't escrowing only the client/server application traffic
>>> secrets (instead of keys higher in the schedule) avoid this
>>> problem? These keys would permit the one capability "visibility"
>>> appliance vendors allege to care about: traffic decryption, without
>>> permitting others like session resumption.
>>> The most obvious escrow design requiring no changes to the clients
>>> is to use a static eDH key on the server-side.  The next most
>>> obvious such design is to have the server talk to the escrow
>>> agent.
>>> It seems like with an out-of-band escrow agent, the traffic secrets
>>> could be escrowed with no changes to TLS.
>>> -- Tony Arcieri _______________________________________________ TLS
>>> mailing list 
>> _______________________________________________ TLS mailing list 
> <0x5AB2FAF17B172BEA.asc>