Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

Daniel Kahn Gillmor <> Mon, 19 March 2018 10:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5274F126FB3 for <>; Mon, 19 Mar 2018 03:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mJUbT2dv0qIC for <>; Mon, 19 Mar 2018 03:39:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FF8A127076 for <>; Mon, 19 Mar 2018 03:39:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id AD12AF99A; Mon, 19 Mar 2018 06:39:05 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 16E102034E; Mon, 19 Mar 2018 10:38:59 +0000 (GMT)
From: Daniel Kahn Gillmor <>
To: Viktor Dukhovni <>, TLS WG <>
In-Reply-To: <>
References: <> <> <>
Date: Mon, 19 Mar 2018 10:38:58 +0000
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
X-Mailman-Version: 2.1.22
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: Mon, 19 Mar 2018 10:39:09 -0000

On Sun 2018-03-18 12:08:13 -0400, Viktor Dukhovni wrote:

> The devices that might use external PSKs will likely be unavoidably
> fingerprinted by source IP address and the target mothership.

I'm not convinced that this is the case -- it's not at all clear that
IoT devices will be attached to a stable network (so the source IP may
change), and for large deployments, the devices might all share the same
"mothership".  But the device might still present significant privacy
concerns (for example, if it's a device that travels with a person, its
presence on the network could be used to track that person). 

> So I agree with the above approach.  It is better to keep external PSKs
> simple, with understood limitations, that to attempt (and fail) to turn
> privacy up to eleven.

fwiw, i agree that a big fat warning about the privacy implications of
reused (if you don't reuse, there is no problem) external PSKs is about
all we can do at this stage of TLS 1.3.