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

Bret Jordan <> Wed, 05 December 2018 11:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E1FE130DCC for <>; Wed, 5 Dec 2018 03:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 c6ChasmrWMSH for <>; Wed, 5 Dec 2018 03:15:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D946130DDA for <>; Wed, 5 Dec 2018 03:15:12 -0800 (PST)
Received: by with SMTP id w6so8868124pgl.6 for <>; Wed, 05 Dec 2018 03:15:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2O81oEOW1PT2cawpMoDX5Ir3FpT0eOKi42ix+IgzjWA=; b=TXQ+GGUOqYh94iyoyN/rnJLBHl9PBF78mFJiw22T4kO8vdjgjEr1VVymwxBPjalcI6 fc8JCfK1EB4mkMoxQaExz8rfuMMuhIIETFxq2vJpRJnJqlh+jKFQCrh5I0Pyzrw+JXeq udSPn6tNEi8nar9nG8iW57EO4kmOQHAkM2xfOfwfX4a5qd1HfCk8twVj12y8UPgdKwHT MPaPMcyPGfj3yd0ZHOwB/rextv8BZbNY0TQRRSTMYtuTUsZdBGzNRmAiOxI6YtQZKr5L 7xIqiuMs7UMd68virked2lConF8Y/xbV5ECI9tmfp9maP95vLMRO3+Pi9Xa2sUFjMSxQ 4nhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2O81oEOW1PT2cawpMoDX5Ir3FpT0eOKi42ix+IgzjWA=; b=p/6QAsNAMlVEE2ZHvdkJLlrF1WUHWOjpzEv8cM+yKRTDKVv4PSReI01fwgcK6QcvRA s9BPt+HgqR5bMzjPA7A+nL9muWd2EdXT38N7eVOJ5Sej5VjUiyYi8qhU3plXFFU1WGrF EFW/ih3sZRVAB2b7vwnlpesPr8AdG6OMjrOkQPJ6KbpnL6ILoLMqUPnmf8WqyruGLJ3V 68q8zvQ3jH9e4hJ0GlTWBXVEdjMvkBD6gB4yKjXixCzmirxn3AwjnzcxipHFenYWbTU7 aiL/Sts7V98AvkOhHv38kyOl4XAjU+yrtADrAoG2e4w2zc1IKT1r/1I9NfylGMLtpOCu LBGw==
X-Gm-Message-State: AA+aEWb17M8H6eIzqFR5+zqczR71lu7cobXGWEhK46Hx4BmrNVmlmVSV Wl7dxBxeMTbHBZNgEWtJsyWVKk7s
X-Google-Smtp-Source: AFSGD/UHMJT/UdN5btDdPA+Jdqy8iFeKikmsutwunb0aUNM23Zcld5Mi7WdZeTJbn2GrVlSmuI8cjg==
X-Received: by 2002:a63:396:: with SMTP id 144mr20316783pgd.68.1544008511555; Wed, 05 Dec 2018 03:15:11 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e23sm27391677pfh.68.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 03:15:10 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-636A0F2E-94AE-490E-A3A1-8E0E0D4E7B5A
Mime-Version: 1.0 (1.0)
From: Bret Jordan <>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <>
Date: Wed, 5 Dec 2018 20:15:08 +0900
Cc: "<>" <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <20181202233553.GD15561@localhost> <> <> <> <> <>
To: Stephen Farrell <>
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 11:15:14 -0000

Comments inline 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Dec 5, 2018, at 7:33 PM, Stephen Farrell <>; wrote:
>> On 05/12/2018 10:22, Bret Jordan wrote:
>> I think we should be more open minded and look at the needs from a
>> 360 degree deployment perspective. 
> I think we should avoid marketing speak.

This is not marketing speak. This is understanding how these solutions need to be deployed end to end in all of their scenarios from consumer, to small business, to enterprise, to service provider, to content provider, to telco, etc.  

>> The real power of the IETF is in
>> looking at all the needs and requirements and designing solutions for
>> them.
> The IETF is sometimes at it's best when it says "no." This
> is one of those cases.

I disagree.

>> 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.
> All of the above was done, at length, and we got a result.
> The TLS WG had no consensus to work on this topic.

Or it could be said the TLS WG had no consensus to not work on it.  When there is a tie who wins? It seems like working on a solution that works for the larger community is the right solution.  The use case and need is a valid requirement.


> S.
>> 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 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>
> <0x5AB2FAF17B172BEA.asc>