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

Tony Arcieri <> Fri, 07 December 2018 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 141CA130E89 for <>; Thu, 6 Dec 2018 16:31:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vfclnbWlDJNy for <>; Thu, 6 Dec 2018 16:31:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C406313124C for <>; Thu, 6 Dec 2018 16:31:00 -0800 (PST)
Received: by with SMTP id x202so2030192oif.13 for <>; Thu, 06 Dec 2018 16:31:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+VZSM6ev75bnnW25OXnvFTlNU3slMj0/zqU640i/pak=; b=PvhNHrvmEXBnPvGlRrJn1yRxEVc2ksDn2yvSa9cnpnIzYRiVHFSvXETS6nf0vfZOAC RAYaB5bG4rym6bELm2yOlgPiRq9S3zZXzeibvwL7zRs/1cJKBOH6ZCyGu3S+L3pdT6Zn oItItQZFyv81JQW+LrxNw8AEL1SKPxX2Ij1M6Y81Xn1binn4U8LMiilwCtd9xyTNFVZj f7XW/hzyHMSa1mIkOeRd6bi24jk99xajBha+w8bznepxyhjKaP83hUz5JZp8fNKyW5pQ HRq8yvJ3Rz85L6ev/kkIADPsOzGkMg3fK67pUkxyXum9koJedDmGX26u58HwIyZRpWhc /FUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+VZSM6ev75bnnW25OXnvFTlNU3slMj0/zqU640i/pak=; b=Ei+FgXI38AkgP5pWlqK4R64xNpQ/0Gvgb3JlFeUznPzYPO+6SBarPiMbXRZB/vtI4B eh9uOR2ABMrTbaRW+ocC8DnAgAYq/XaRBLYRN76i/pveZ5RcQDFWp3H8e24mh3vSFVJ9 WLYsD0pT3dGTnab3+b5bCZ8xFcgkB3mh7EckkLbxHVA1GKaacOyAWFrwvBJqo9Cw8Ikj y3Gjx3XMvM4RPxAUkvYCjqjIUS8NAH1zbwrTn330CooWvG0jjJ/1gIK5VrSemTvTB/nZ avgwTp2NgStuHRLF9dcv3Kbd2qcAxDeigScRT6aHyBvN4MQOSl5XrmXIRcxZbBD72EVv m5Zw==
X-Gm-Message-State: AA+aEWafgM/MnQ7I/MuWB/tjllXD5SEOgqb3C8hHBNViUSiaPGdwAWZi Tvmc+koeCcOZ4503lpZdalUBxs6AERoMf+pZGZmEeQ==
X-Google-Smtp-Source: AFSGD/ULv85kO8a6zVRZNiwcaGOImtoW4w+QPxzyHC5u1daS8gh1O2WtrRtACHYFe7hBGPEc1Iu9T+KBojxIXpY2o94=
X-Received: by 2002:aca:ba02:: with SMTP id k2mr46859oif.177.1544142659833; Thu, 06 Dec 2018 16:30:59 -0800 (PST)
MIME-Version: 1.0
References: <> <> <20181202233553.GD15561@localhost> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tony Arcieri <>
Date: Thu, 6 Dec 2018 16:30:48 -0800
Message-ID: <>
To: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000b8d52e057c63baf7"
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: Fri, 07 Dec 2018 00:31:06 -0000

On Thu, Dec 6, 2018 at 3:30 PM Viktor Dukhovni <>;

> > On Dec 6, 2018, at 4:08 PM, Andrei Popov <Andrei.Popov=
>>; wrote:
> >
> > Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing
> connections to "enterprise TLS" servers would probably qualify as
> "essential circumstances", at least to some operators.
> I don't think the TLS WG or IETF can win this skirmish.

I think there are very strong technical/security reasons to reject using a
static D-H key in place of an ephemeral D-H key, namely compromise of this
key permits "impersonation" of any previously (passively) observed TLS
sessions by allowing a passive observer holding one of these keys to
recover the resumption master secret.

In as much as people are attempting to build standards around this
approach, based on the conversation earlier in this thread it seems they
were unaware of this security property. I hope this causes the creators of
"eTLS" to reconsider the security implications of their proposal.

I think a protocol which aims to fulfill the specific goals of "eTLS"
should focus on providing a way for a passive observer to recover the
*traffic* secrets, which would provide the ability to passively decrypt
traffic (something I think is a bad idea, but I digress), but *NOT* resume
observed sessions.

Tony Arcieri