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

Nick Lamb <> Wed, 19 August 2020 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 216343A043E; Wed, 19 Aug 2020 15:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hyNJFSbEpYpH; Wed, 19 Aug 2020 15:43:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D3C33A0EBF; Wed, 19 Aug 2020 15:43:24 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 2A9577E176A; Wed, 19 Aug 2020 22:43:24 +0000 (UTC)
Received: from (100-96-19-54.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 831B07E11F9; Wed, 19 Aug 2020 22:43:23 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.8); Wed, 19 Aug 2020 22:43:24 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Reaction-Supply: 60ab95094bf34615_1597877003996_3731062712
X-MC-Loop-Signature: 1597877003996:1742534597
X-MC-Ingress-Time: 1597877003995
Received: from (localhost []) by (Postfix) with ESMTP id 191537E73D; Wed, 19 Aug 2020 15:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding;; bh=Ogdxwi/ EaeZm1ee3VUn9fCmsP2Q=; b=OqwkVLJTpxk8b9+DEcG64cUhOFmIUas4i2G14Ls vyTG6BKUfqn0lSp0gW5OJ1D8eM79aP3W3S9AFp/plhAPVDAOWjG4CQwca5VOmoTI QhnPNDYAATUoxmaLWjEOdP+uWydXiCYQ86XYM3XV2QXhmD3HVpbPxDE5eQNft4hm 3P18=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 477C47ED64; Wed, 19 Aug 2020 15:43:18 -0700 (PDT)
Date: Wed, 19 Aug 2020 23:43:14 +0100
X-DH-BACKEND: pdx1-sub0-mail-a90
From: Nick Lamb <>
To: "Nancy Cam-Winget (ncamwing)" <>
Cc: "" <>, "" <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
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: gggruggvucftvghtrhhoucdtuddrgeduiedruddtledgudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfgjfhfogggtgfesthejredtredtvdenucfhrhhomheppfhitghkucfnrghmsgcuoehnjhhlsehtlhhrmhigrdhorhhgqeenucggtffrrghtthgvrhhnpeetjeeludefvddtkeffgffgudfgveffffegtdeuleffkedvvedvfedvjedvleelueenucfkphepkedurddvrdekledruddvgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehtohhtohhrohdrthhlrhhmgidrohhrghdpihhnvghtpeekuddrvddrkeelrdduvdegpdhrvghtuhhrnhdqphgrthhhpefpihgtkhcunfgrmhgsuceonhhjlhesthhlrhhmgidrohhrgheqpdhmrghilhhfrhhomhepnhhjlhesthhlrhhmgidrohhrghdpnhhrtghpthhtohepohhpshgvtgesihgvthhfrdhorhhg
Archived-At: <>
Subject: Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
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, 19 Aug 2020 22:43:27 -0000

On Wed, 19 Aug 2020 18:45:44 +0000
Nancy Cam-Winget (ncamwing)" <> wrote:  
>     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.
> [NCW] The document describes what is in practice today with TLS 1.2
> and 1.1 whether we believe it is unsound or otherwise, it is what is
> done today.

It's not a problem for the document to describe today's practices but
it's a mistake to label them "effective" if we know they are not.

>     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.
> [NCW] Again, the document is describing what is in practice today.

Describing something as "effective" when it is not effective isn't a
matter of today's practice but of a misunderstanding of what's
possible at all.

>     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. [NCW] With TLS 1.2 the observer can see the handshake thru
> completion with the Finished message before affecting a policy
> decision.

The passive eavesdropper can indeed see the handshake in TLS 1.2, but
since they were not a participant they don't actually know what it
means even though it wasn't encrypted.

For example, suppose an RSA certificate is sent and the handshake seems
to agree RSA key exchange and Client sends an EncryptedPreMasterSecret.
The passive eavesdropper has no idea if that's actually encrypted to the
RSA public key from the certificate, it's just an opaque blob.

Thus it's easily possible for an eavesdropper to witness a handshake in
which the eavesdropper believes what happened is:

Client proposed to do RSA key exchange
Server showed a certificate for www.local-hospital.example
Client sent an EncryptedPreMasterSecret to the local hospital
both agreed this all worked fine and continue encrypted

The eavesdropper's "Don't eavesdrop on people's medical stuff" policy
kicks in and it allows the connection unmolested. Unfortunately what
really happened is:

Client proposed to do RSA key exchange
Server showed a certificate for www.local-hospital.example
Client sent an EncryptedPreMasterSecret for the GRU data exfiltration
server ignoring the bogus certificate
$5Bn of stolen commercial documents are uploaded to the server