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

Carrick Bartle <cbartle891@icloud.com> Fri, 21 August 2020 05:03 UTC

Return-Path: <cbartle891@icloud.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AA43A1836 for <tls@ietfa.amsl.com>; Thu, 20 Aug 2020 22:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_6JZRsM8pkI for <tls@ietfa.amsl.com>; Thu, 20 Aug 2020 22:03:18 -0700 (PDT)
Received: from mr85p00im-ztdg06021801.me.com (mr85p00im-ztdg06021801.me.com [17.58.23.195]) (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 020783A1832 for <tls@ietf.org>; Thu, 20 Aug 2020 22:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; 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 [17.235.47.109] (unknown [17.235.47.109]) by mr85p00im-ztdg06021801.me.com (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 <cbartle891@icloud.com>
In-Reply-To: <c19cd6c1-e66a-416b-99b4-def2e55ec0e7@www.fastmail.com>
Date: Thu, 20 Aug 2020 22:03:11 -0700
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D398C0C9-FF10-4FAC-A9A4-E3956354D05D@icloud.com>
References: <3359D367-16E3-4C30-B434-A8043B1F253A@icloud.com> <841bd643-d7bf-4211-a40c-9121967b67b6@www.fastmail.com> <4659F6E4-D167-4CBC-B9CE-1DF110AAE5D7@icloud.com> <c19cd6c1-e66a-416b-99b4-def2e55ec0e7@www.fastmail.com>
To: Christopher Wood <caw@heapingbits.net>
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: <https://mailarchive.ietf.org/arch/msg/tls/meyCSNmYPatWYe4DxYT58fBT92E>
Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00
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: 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 <caw@heapingbits.net> 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: https://github.com/tlswg/external-psk-design-team/issues/36
>> 
>> 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