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

Carrick Bartle <> Fri, 21 August 2020 05:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19AA43A1836 for <>; Thu, 20 Aug 2020 22:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Status: No, score=-1.849 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2_6JZRsM8pkI for <>; Thu, 20 Aug 2020 22:03:18 -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 020783A1832 for <>; Thu, 20 Aug 2020 22:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1a1hai; t=1597986196; bh=1yhJSI3D+9rU8czlo88RfuwnuaqTMZyxzSYxYggKHCw=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=heyI2ZtDTtTbc8TDIeKywFs78TkKyvXISOJj1cwousjw6RqrYpQJNotXxGU1paHq5 Dne2LZBCgdW0+8xwSW6XNTXcKX/rYyum9lXU/fpZoC7rKcql77w+f98CkHR8MRTSKx jW+TZc79qruVlXvuZngGsGmYNNsGb3EzWknzW3mq0qQYuI5RKOtyzlOPPU0QMG9Hvq G7QJZ9rcey5GFsfnr9LlnbWNJnuWyUjfrX+fmVtSdw01ccOiHL3/Khc3R9f3fcg+FK ucAyaxt1AIUYuZPouNjl6Ogx+P1SK7nqJQ/nghz0lp4qPl/gKJngHF305zJkc6Eoc8 VOl8yfvYmXu2Q==
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 7644818050B; Fri, 21 Aug 2020 05:03:16 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.7\))
From: Carrick Bartle <>
In-Reply-To: <>
Date: Thu, 20 Aug 2020 22:03:11 -0700
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Christopher Wood <>
X-Mailer: Apple Mail (2.3622.0.7)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-21_03:2020-08-19, 2020-08-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=942 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2008210048
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: Fri, 21 Aug 2020 05:03:24 -0000

Cool, I'll propose some text in the cases you mentioned.

> On Aug 20, 2020, at 6:10 AM, Christopher Wood <> wrote:
> 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!
> Best,
> Chris