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

Bret Jordan <> Wed, 05 December 2018 08:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16598129BBF for <>; Wed, 5 Dec 2018 00:09:07 -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 2idAGsngk0aM for <>; Wed, 5 Dec 2018 00:09:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 842E2124D68 for <>; Wed, 5 Dec 2018 00:09:04 -0800 (PST)
Received: by with SMTP id t13so8636801pgr.11 for <>; Wed, 05 Dec 2018 00:09:04 -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=c6iGgFfeI2YBDvBE6WlocxQOrUw1Zsp17D/suZSui5Y=; b=tVrAiooRt8rvpuckP4W0pRcj488QNwAYxd9veC3rhU+keaocSdsl1y9iirF+ijeqqq pXWsohbfHbVuuhzkIMK37U7MdUziAihN9Hx23ag4K+7xffVlAleVb+Lqdhgtr4vyhP6U T+5NK/6ElfsIkrWRbi9DScTKO8o3WyzDnVS2f/Hl7Zs4YhlwKOZF02xy8kNLNMXPkJOT PyR7gDUOU2PdpARB8R2vMfpzTiYRY/lBlJjrl/LEJ3e4fc4F7DeXGwei2htHQ21JHwR/ Pn0M+Q0/pr/NWADiqoklfteuUJde72KP1KmcwmOxLQqq9+rKyla4EaOy3PJnNgVsBt7R 4KhQ==
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=c6iGgFfeI2YBDvBE6WlocxQOrUw1Zsp17D/suZSui5Y=; b=LU1nFDhSEb3fBtwh+QM6FqSBNvht1zt7yWhiG+Kx9yUadeVtiaxGdEgkm6vztCwkeQ TJPMSr7KDYj5Ulq8/9WFYx1EA1WHI5xxzb+uMoIygj/uYzWj0WcDoqwrmqlt3oYJuww3 XZnYoBWqC+yv9qRLS6V2FzL5pQ+PVWWPpE8GPQ2m/NaigfFMJ4WCcY4PfBTTKJDa6U/m BTYTOXYJz7N2EPk6jtHPvPisd5Za67D/IHDs3oYX6xu82t7UkyBE9e51AgThY7fznoPH AKrvCpEU2Gy9PlNcfjN++vwPtUK+tYHgkm+HEWVYanAgtY058255fSvEpwFPO3rGLgkZ ttMA==
X-Gm-Message-State: AA+aEWaKt2tT6c3rvgUEVLGS+c5QWyJbf8WcyfPL5VvX/Eftuxwo11Or xIvHGBIqAYdUHSjxT7MxBPEL1YBd
X-Google-Smtp-Source: AFSGD/VpstLA2XO4gNSGpATvY1UBRRO0kEVPnoyPnx2/uIOMf+Ehu5BgK1PlW4F2yR2CnUf7wDa0mg==
X-Received: by 2002:a63:a16:: with SMTP id 22mr19676022pgk.318.1543997344095; Wed, 05 Dec 2018 00:09:04 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id f64sm62939263pfh.0.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 00:09:03 -0800 (PST)
From: Bret Jordan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_31A5328B-10CE-45FC-9B80-87BA73E47A78"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 5 Dec 2018 17:08:44 +0900
In-Reply-To: <>
Cc: Nico Williams <>, Crypto <>, "<>" <>
To: Tony Arcieri <>
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 08:09:07 -0000

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.

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

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