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

[Carrick Bartle <[e-mail]>]

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.)

>>> 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?

>>> 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?

>>> 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.

>>> 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?

Carrick





> On Aug 18, 2020, at 8:26 AM, Christopher Wood <[e-mail]> wrote:
> 
> Hi Carrick,
> 
> Sorry for the delay. Please see inline below!
> 
> On Thu, Jul 9, 2020, at 10:09 PM, Carrick Bartle wrote:
>> Isn’t the rerouting attack described in Section 4 not possible if "A" 
>> uses the SNI extension and "C" aborts the connection on mismatch? If 
>> so, it might be worth mentioning that as a potential mitigation (as the 
>> Selfie paper does).
> 
> Indeed. That seems like a fine thing to mention.
> 
>>> "C" has completed the handshake, ostensibly with "A".
>> "C" did in fact complete the handshake with "A." (Without mistaking it 
>> for some other endpoint or something.)
> 
> +1, I'm fine with dropping that bit.
> 
>>> 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?
> 
>>> Applications should take precautions when using external PSKs to mitigate these risks.
>> What sort of precautions should they take?
> 
> Filed: https://github.com/tlswg/external-psk-design-team/issues/36
> 
>>> 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. 
> 
>>> Below, we list some example use-cases where pair-wise external PSKs 
>> with TLS have been used for authentication.
>> I assume "pair-wise" here means a PSK is shared between only one server 
>> and one client, but this the term "pair-wise" hasn't been associated 
>> with that concept in this document, it's not completely clear. Since 
>> "pair-wise" is used twice in the document, maybe define it when the 
>> concept is first introduced.
> 
> Yep, I agree.
> 
>>> primarily for the purposes of supporting TLS connections with fast 
>> open (0-RTT data)
>> I've only ever heard "fast open" used in the context of TFO, which is 
>> distinct from (albeit similar to) 0-RTT. Using "fast open" to refer to 
>> 0-RTT sounds like it's conflating terms. Shouldn't "early data" be used 
>> here instead of "fast open"?
> 
> I think the two phrases are basically equivalent, but if using "early data" is more clear, let's go with that. 
> 
>>> In this use-case, resource-constrained IoT devices act as TLS clients 
>> and share the same PSK.  The devices use this PSK for quickly 
>> establishing connections with a central server.  Such a scheme ensures 
>> that the client IoT devices are legitimate members of the system.
>> If the IoT devices only talk to a central server and not each other, 
>> why do they all need the same PSK?
>> 
>>> To perform rare system specific operations that require a higher 
>> security level, the central server can request resource-intensive 
>> client authentication with the usage of a certificate after 
>> successfully establishing the connection with a PSK.
>> If you're going to authenticate with a cert, why bother preceding that 
>> with an authentication with a PSK?
> 
> Good question. I'll let Mohit answer this, but my impression was that, unlike the PSKs, each node has its own private key, which seemingly allows the server to authenticate a specific client.
> 
>>> 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. 
> 
>>> Moreover, PSK production lacks guidance unlike user passwords.
>> Isn't that precisely the point of this draft? Seems unnecessary to 
>> mention. (Or it might be better to move this point to the intro as a 
>> motivating factor of this document.)
> 
> Great suggestion!
> 
>>> PSK provisioning systems are often constrained in application-specific ways.  For example, although one goal of provisioning is to ensure that each pair of nodes has a unique key pair, some systems do not want to distribute pair-wise shared keys to achieve this.
>> Why not? What application-specific constraint would warrant that?
> 
> Pointing again to Mohit for the IoT case. :-)
> 
> (We might just replace "do not want to" with "might not want to", and leave it at that.)
> 
>>> 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. 
> 
>>> 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. 
> 
>>> Applications MUST use external PSKs that adhere to the following 
>> requirements:
>> I think you mean "If an application uses external PSKs, the PSKs MUST 
>> adhere to the following requirements." Otherwise it sounds like you're 
>> saying every application must use an external PSK.
> 
> Yep, that would be more clear.
> 
>>> Each PSK SHOULD be derived from at least 128 bits of entropy
>> Recommend a particular method for doing that?
> 
> I don't think that's necessary. Any suitable method will suffice.
> 
>>> Note that these mechanisms do not necessarily follow the same 
>> architecture as the ordinary process for incorporating EPSKs described 
>> in this draft.
>> Where was the ordinary process for incorporating EPSKs described? Is 
>> "incorporating" a PSK the same as "provisioning" one? If so, several 
>> ways were described. What's the problem with these mechanisms (e.g. 
>> PAKE) having a different architecture from these ordinary processes? 
>> Are they not compatible?
> 
> I'm not seeing this text in the editor's copy, so I'm not sure what the context is.
> 
>>>   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. 
> 
>>> 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. 
> 
>>> PSK identities MAY have a domain name suffix for roaming and federation.
>> What do roaming and federation mean here? Is there a source that discusses this?
> 
> Hmm, probably? Mohit, can you please drop in a reference?
> 
>>> Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions.
>> What's the difference between a "collision" and an "obvious collision"?
> 
> Nothing. We can drop "obivous."
> 
>>> This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK.
>> How should the application handle the collision?
> 
> That's an application-specific decision, so we don't specify it. 
> 
>> I'm happy to make the suggested changes in a PR if they look ok.
> 
> Yes, please!
> 
> Best,
> Chris
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls