[TLS] OpSec WGLC for draft-ietf-opsec-ns-impact

Nick Lamb <njl@tlrmx.org> Mon, 17 August 2020 15:39 UTC

Return-Path: <njl@tlrmx.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 20C753A0CCD; Mon, 17 Aug 2020 08:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tlrmx.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FzSrnp2iCA-y; Mon, 17 Aug 2020 08:39:46 -0700 (PDT)
Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B983A0B94; Mon, 17 Aug 2020 08:39:46 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org
Received: from relay.mailchannels.net (localhost []) by relay.mailchannels.net (Postfix) with ESMTP id 545252209A; Mon, 17 Aug 2020 15:39:45 +0000 (UTC)
Received: from pdx1-sub0-mail-a31.g.dreamhost.com (100-96-5-126.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DC22121CAF; Mon, 17 Aug 2020 15:39:44 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org
Received: from pdx1-sub0-mail-a31.g.dreamhost.com (pop.dreamhost.com []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.8); Mon, 17 Aug 2020 15:39:45 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|njl@tlrmx.org
X-MailChannels-Auth-Id: dreamhost
X-Skirt-Abiding: 69fcdad9221ad991_1597678785141_490892859
X-MC-Loop-Signature: 1597678785141:1491327578
X-MC-Ingress-Time: 1597678785141
Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost []) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id 8D91B7F0EE; Mon, 17 Aug 2020 08:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tlrmx.org; h=date:from:to :cc:subject:message-id:mime-version:content-type :content-transfer-encoding; s=tlrmx.org; bh=rosz/lqeIliYoYjVf7Ci 9pGFTQk=; b=XPiMbYH4t5d31Pud/+xQpqtEHhfvsfDEIu0e/XwGcXUPd09LHdcG DNX47ZUrYq1bKIWLBNFb6uL+3lqmAR+K/amAOpDJ5XuLkw0x7+L2D7+Tfact4Gcx 8rpcAHhDHJ1X/Z8SccGc3Sh555ovsrwmrICwa2Dm7cYWXpof+Te3N0g=
Received: from totoro.tlrmx.org ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: njl@tlrmx.org) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 9B2627F0F4; Mon, 17 Aug 2020 08:39:43 -0700 (PDT)
Date: Mon, 17 Aug 2020 16:39:38 +0100
X-DH-BACKEND: pdx1-sub0-mail-a31
From: Nick Lamb <njl@tlrmx.org>
To: tls@ietf.org
Cc: opsec@ietf.org
Message-ID: <20200817163938.07580cee@totoro.tlrmx.org>
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedruddtfedgkeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkofggtgfgsehtjeertdertddvnecuhfhrohhmpefpihgtkhcunfgrmhgsuceonhhjlhesthhlrhhmgidrohhrgheqnecuggftrfgrthhtvghrnhepfeekteeigeejvdfgvedtffffieekudekfeelhffhfeefieeigfekheegffehveefnecukfhppeekuddrvddrkeelrdduvdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepthhothhorhhordhtlhhrmhigrdhorhhgpdhinhgvthepkedurddvrdekledruddvgedprhgvthhurhhnqdhprghthheppfhitghkucfnrghmsgcuoehnjhhlsehtlhhrmhigrdhorhhgqedpmhgrihhlfhhrohhmpehnjhhlsehtlhhrmhigrdhorhhgpdhnrhgtphhtthhopehophhsvggtsehivghtfhdrohhrgh
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/m_anGU9yrrdcfDWKQPqDhcf6HVA>
Subject: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 15:39:48 -0000

I am not very familiar with IETF working group practices, however it
strikes me as surely unusual to have a document enter Last Call
(supposedly believed by its owners to be ready for publication) and yet
immediately then be revised showing it was in fact not ready at all.

However this seems to be what happened to draft-ietf-opsec-ns-impact.
The below comments concern draft-ietf-opsec-ns-impact-02, the newer

Section 4.1 Perfect Forward Secrecy ends:

> TLS session data.ss

I think this is a typographical error and the trailing "ss" should be
removed from the document. If not it should be explained.

Section 4.2 Encrypted Server Certificate describes a practice which is
inherently unsound. Passive inspection of the Certificate message from
TLS 1.2 or earlier isn't a reliable source of information because a
passive eavesdropper isn't able to discern whether the X.509 document
presented corresponds to this server or not. The Client can confirm
this using the TLS protocol but an eavesdropper can't. So the change in
TLS 1.3 does not impact the practical security policy available, only an
appearance is altered.

Passive systems described throughout Section 5.1 fall to this same
error, using the phrase "reduced effectiveness" which the document
defines as not being "as effective on TLS 1.3 traffic" but in fact
since this practice didn't work, it will remain exactly as effective
(not at all) as before.

A related consequence passes into Section 5.2. Since the Certificate
message is only reliable for a Client, it has in fact always been
necessary to fully proxy the TLS session in order to rely on this data,
so this is not in fact an impact from TLS 1.3 but (if it wasn't done
previously for all versions) a vulnerability in such products.

As it stands then, this document is misleading.