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

From: "Christopher Wood" <[email-masked]>
Date: Tue, 18 Aug 2020 08:26:41 -0700

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

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 19 Aug 2020 07:43:30 +0000

Hi Carrick,

Thank you for the review. I also added some comments in-line.

On 8/18/20 6:26 PM, Christopher Wood wrote:
> Filed:https://github.com/tlswg/external-psk-design-team/issues/36
>
This use-case is described in the publication by Akhmetzyanova et al. 
https://eprint.iacr.org/2019/421.pdf. See section 4. In the scenario 
described by the authors, resource-constrained IoT devices are TLS 
clients. The PSK is used for authenticating the central server and 
client membership of the system. Only for rare device-specific 
operations requiring a higher-security level (such as device firmware 
update), the server can request resource-intensive client authentication 
with certificates after successfully establishing the connection with 
PSK. This deployment may seem somewhat artificial but it was necessary 
in the paper to explain the possible attack scenarios.
> (We might just replace "do not want to" with "might not want to", and leave it at that.)
This text is based on the input from Björn Haase. Essentially, he 
indicated that some industrial control deployments do not want to have 
O(n^2) keys for a system with n nodes, but they do want to minimize 
sharing. I am fine with changing it to "might not want to" or removing 
this constraint completely.
> 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.
A citation for EAP-TLS-PSK is added in the github version of the 
document. I agree that "routable" identities is not something obvious 
and could be better explained. In standard AAA (Authentication, 
Authorization and Accounting) architecture, client devices send an 
identity for network access authentication. These identities are in the 
form of a Network Access Identifier (define in RFC 7542: 
https://tools.ietf.org/html/rfc7542). Nodes in the network such as 
access points (also called as authenticators) look at the identity 
(mostly the domain name suffix at the end of the identity) to determine 
if they should proceed with the authentication request and for figuring 
out the appropriate EAP server where the authentication request should 
be sent. Perhaps that sentence could be re-written as: "PSK identities 
may sometimes need to have a domain name suffix, as is currently under 
discussion for EAP-TLS-PSK [I-D.mattsson-emu-eap-tls-psk]".

> Hmm, probably? Mohit, can you please drop in a reference?

I didn't find any standard definition of federation even though many 
RFCs have used them in the past (RFCs 2552,3313,7532). We could add a 
reference to roaming defined in RFC 2904: 
https://tools.ietf.org/html/rfc2904#section-3.2 and drop federation. 
Would that work?

--Mohit

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 19 Aug 2020 18:42:21 -0700

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

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

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

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

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

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

> 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 <[email-masked]> wrote:
> 
> Hi Carrick,
>

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 20 Aug 2020 06:10:19 -0700

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:
> 
> >>> 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? 
> 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." 

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

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

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

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

---

From: Carrick Bartle <[email-masked]>
Date: Thu, 20 Aug 2020 22:03:11 -0700

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

> On Aug 20, 2020, at 6:10 AM, Christopher Wood <[email-masked]> wrote:
>