Hi Carrick, Thank you for the review. I also added some comments in-line.
On 8/18/20 6:26 PM, Christopher Wood 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. 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. >>> 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.) 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. > >>> 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. 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]". >>> 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? 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 >>> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
