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

[Carrick Bartle <[e-mail]>]

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


> On Aug 20, 2020, at 6:10 AM, Christopher Wood <[e-mail]> 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