Cool, I'll propose some text in the cases you mentioned.
> On Aug 20, 2020, at 6:10 AM, Christopher Wood <c...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
