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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
