Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

Christopher Wood <> Thu, 20 August 2020 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B9C03A091C for <>; Thu, 20 Aug 2020 06:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=ABGVtnOK; dkim=pass (2048-bit key) header.b=NiEyEuGt
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YdJN3obW0D27 for <>; Thu, 20 Aug 2020 06:10:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A4453A08D4 for <>; Thu, 20 Aug 2020 06:10:46 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 332705C01E4; Thu, 20 Aug 2020 09:10:45 -0400 (EDT)
Received: from imap4 ([]) by compute1.internal (MEProxy); Thu, 20 Aug 2020 09:10:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=q6C0nbs3gwNAHrG7v7SuIhEb5iHM I0PfsK8ovFRa5tc=; b=ABGVtnOKYrS1im/oUe2+Im+3CzI8vrMh1MZy9vDMtTQd 90Ozg43MuVzzSh8usA7zGTk51err5qSwCeiMXOMFEB5t0VJkj0coXDFTDtZUCEqw 1PlbJnvkAbI2zyhIOT7jbJCsLaMhBjsEoB37o9lzPEUKwbpdY+/com3yxGw+HOK0 gwQ91gelGRYW7bGkbfoybNn9fUb0/YtHTCVJoi19VfmgfzlILhvQUBTRJ31VU/AG zSkcCojN8kUlsiznaDJSDDqZXHCj4CWNYR5IOm/JZ99Q7hYYRPqoux9tU8ZWCYnf Kyxofj2oqOef1BPKNIoC/wsS4CWMNJ7qTa9w/7G0wg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=q6C0nb s3gwNAHrG7v7SuIhEb5iHMI0PfsK8ovFRa5tc=; b=NiEyEuGtyizXcLW5X4g7eq ds/5t8B0slIvGq+BkTpF6QeQnyfdNsuHTMh6FrmroLFUXJeLw0ECjhIKlw6M0K6P Nqmmtbb5y5bzHSv+pOvZt98Y4ojxF+ZXJ3oyQaZTTuy/AJg8phCkkJfU5kBKiXTX Y6BJO8GEuKFfwxf9Xv6mrEPBk4c8axKOB5noVzNdYzKcgV3PZ93nXHt35Jn4dmnb 0Y8V5p20s2ISaV9mX1x9+WD6T97TpWYgxsYIOhKJoPX6uNvdeQ3MsMHvCvPJ2r/4 PXcgkhxiWxmW4pocM9SzQDvF69fhXmk2UtCXMv1mRMiltZE18DSc16QyEP4prPGA ==
X-ME-Sender: <xms:VHY-XzKNhF1Kar3uN0nJxb81KhXNuV7X7wb2-t6YR4o9sepb9S_nbA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddutddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepveekgedtgfdtjefhteeifeejhfdtgfdufedufeeljeeu vdejtdfhvefgvefgvedtnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhi nhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:VHY-X3ImWbZIZft4ity6-za4rLYsmMu08MvUVAEwBxtUpNUhjOMMrg> <xmx:VHY-X7si-AB-_OPmJYiOjoNoHFXldWJnLCIG_SmBibqdsJ5aBrxUzg> <xmx:VHY-X8Y3Isw5byBWTutm4skIaN8ceik65RGgo_Sp8fbjTN1aT1KX7A> <xmx:VXY-XzmsUmSdc9mrENVYnrENwp2rz74oihi3FItdyxqmZx2b6Cdiew>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C03C33C00A1; Thu, 20 Aug 2020 09:10:44 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-214-g5a29d88-fm-20200818.002-g5a29d882
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Date: Thu, 20 Aug 2020 06:10:19 -0700
From: Christopher Wood <>
To: Carrick Bartle <>
Cc: "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00
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: Thu, 20 Aug 2020 13:10:49 -0000

On Wed, Aug 19, 2020, at 6:42 PM, Carrick Bartle wrote:
> Thanks for the feedback! I've posted a bunch of PRs and issues, as 
> you've seen. Here are my remaining comments:
> >>> Low entropy keys are only secure against active attack if a PAKE is 
> >> used with TLS.
> >> Maybe cite a document that contains a recommended way of using PAKEs 
> >> with TLS (e.g. draft-sullivan-tls-opaque-00)?
> > 
> > I'd rather not cite one (now), especially since that document is expired. Perhaps we can file an issue to add a citation later on?
> Looks like Mohit already added a more up-to-date citation.
> > Filed:
> Thanks, Mohit! :)
> >>> Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication.Isn't mutual authentication, in general, orthogonal to linkability? 
> >> Certificates, for example, are encrypted in TLS 1.3, and so cannot be 
> >> linked across connections.
> > 
> > This section speaks of linkability by the endpoints, not the network. Any sort of identifier that's reused across connections can be linkable, be it an external PSK ID or a certificate. 
> Right, I get that. What I'm saying is that since there are solutions 
> that can prevent that type of linkability (for instance, if a third 
> party deals the PSKs to the server and clients, and those PSKs are 
> never used more than once), the fact that PSKs are designed to support 
> mutual authentication is irrelevant. (I.e., mutual authentication for 
> one connection doesn't necessarily imply that the server knows it's 
> talking to the same client on every connection that client makes.)

I think the preceding sentence provides the missing context:

"Specifically, servers can link successive connections that use the same external PSK together. Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication."

That said, I see what you're saying. We can just drop "as PSKs are explicitly designed to support mutual authentication." 

> >>> 6.1.  Provisioning Examples
> >> This section contains a list of ways to provision PSKs, but mostly 
> >> without any commentary or discussion. Are these methods good? Bad? Are 
> >> there any pitfalls? If so, how can one guard against them?
> > 
> > It's meant to be informational without any comment on the pros and cons of each. 
> But the title is "*Guidance* for External PSK Usage." What is guidance 
> if not a collection of recommendations?

This particular bit of the document describes use cases which informed the guidance (recommendations) for PSK usage described elsewhere.

> >>> Identities may sometimes need to be routable, as is currently under 
> >> discussion for EAP-TLS-PSK.
> >> What does it mean for an identity to be "routable"? Also, EAP-TLS-PSK 
> >> needs a citation link. I'm not sure which document it's referring to.
> > 
> > It might be, for example, a FQDN. Mohit understands the EAP-TLS-PSK use case better than I do, though, so I'll let him answer. 
> Looks like Mohit added a citation for that.
> >>>   3.  Nodes SHOULD use external PSK importers [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a pair of TLS client and server.
> >> Why?
> > 
> > Because that interface exists to enable external PSKs for TLS 1.3 and beyond. 
> My understanding is that that interface doesn't *enable* external PSKs 
> for 1.3, but that it just to makes it easier and less error-prone 
> because the interface generates several PSKs--one for each hash 
> function. Is that the case? If so, why not mention that as the 
> rationale as to why nodes SHOULD use the importer?

That seems like a fine clarification. Do you want to propose some text?

> >>> OpenSSL and BoringSSL: Applications specify support for external PSKs 
> >> via distinct ciphersuites.
> >> This is not true of BoringSSL for TLS 1.3. Although the paragraph goes 
> >> on to mention "new callback functions added specifically to OpenSSL for 
> >> TLS 1.3 [RFC8446] PSK support," this doesn't preclude 1.3 PSK support 
> >> in BoringSSL.
> > 
> > We didn't want to go into version-specific details here, but yes, that's right. 
> Might be better to mention this particular version-specific detail here 
> since otherwise this statement is misleading.

That sounds reasonable. Can you please propose text?

> >>> some systems require the provisioning process to embed 
> >> application-specific information in either PSKs or their identities.
> >> Is it really a good idea to embed data in the PSK itself? Does that not 
> >> diminish the entropy of the PSK? Why is it not sufficient to put that 
> >> sort of information in the identity?
> > 
> > It is probably desirable to use the identity for this purpose since, 
> well, its application-specific identifying information. This is just 
> commenting on the state of affairs, I think.
> Okay, but if this document is guidance and not just a description, 
> shouldn't it also comment on whether this state of affairs is a good 
> idea?

As above, this section is more about documenting the situations and use cases which informed the recommendations. I don't think commenting on the pros and cons of the solution beyond that is needed.

Thanks again!