Hi everyone, A few thoughts on draft-ietf-tls-external-psk-guidance-00:
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). > "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.) > 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)? > Applications should take precautions when using external PSKs to mitigate > these risks. What sort of precautions should they take? > 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. > 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. > 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"? > 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? > 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? > 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.) > 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? > 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? > 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. > 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. > Each PSK SHOULD be derived from at least 128 bits of entropy Recommend a particular method for doing that? > 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? > 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? > 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. > 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? > 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"? > 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? I'm happy to make the suggested changes in a PR if they look ok. Carrick _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
