Reviewer: Darrel Miller Review result: Ready with Nits I have reviewed draft-ietf-tls-external-psk-importer-07 but must qualify my review with the fact that I have minimal background in this technical area. Section 1: The paragraph states that in TLS 1.3 "each PSK only be used with a single hash function" and goes on to say in TLS 1.2 "a PSK may be used with any hash algorithm". The first seems to suggest a constraint on how many times a PSK can be used, whereas the second appears to be talking about the set of hash algorithms that a PSK can be used with. This could simply be my ignorance, but I got hung up on it. Would it be correct to replace "any" with "many"? "Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions" Is this saying "Applications SHOULD provision PSKs for TLS 1.3 separately from PSKs for prior versions"? Or is it saying "Applications SHOULD provision separate PSKs for each TLS version"? If I have understood the goal of this document, I found the use of phrases like "differentiating external PSKs" and "External PSK Diversification" misleading. The process seems to be taking external PSKs and deriving new PSKs to avoid the problem of PSK reuse. If that is the case, then the phrase "In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string." would be clearer to me as something like "In particular, it describes a mechanism for importing PSKs derived from external PSKs by including the target KDF, (D)TLS protocol version, and an optional context string to ensure uniqueness." I must reiterate that these technical terms are largely opaque to me, so I may be missing many realities. Section 3: nit: "Each of these derived PSKs are bound a target protocol, KDF identifier, and optional context string." Should this be "bound to"? "Through this interface, importing external PSKs with different identities yields distinct PSK binder keys." This raises the question for me, is it important that the imported PSK be unique, or that the PSK binder key be unique? It is mentioned that the derivation creates a set of PSKs and Identities. The notion of "Imported Identity" is described in the terminology but "PSK binder key" is not. Are these the same thing? "Non-imported and imported PSKs are distinct since their identities are different on the wire." Is the "on the wire" qualification important? It causes me to ask the question, does the identity of a PSK change when it goes on the wire? Are the Identities not different when not on the wire? Section: 3.1 This was very helpful for me. For me it would have been easier to read the overview if the terminology had come first and was used there. Section: 4.1 "External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions." Is the "External" qualifier necessary? The next sentence uses the phrase "non-imported PSKs" and I find myself asking if there is a significance to that distinction. I think there isn't, but from a comprehension perspective it is extra terminology to process. In the 6th paragraph it is mentioned that the Imported Identity is stored in a PSK extension. That was a helpful concrete implementation detail that would have been useful to know in the first paragraph. "The hash function used for HKDF [RFC5869] is that which is associated with the EPSK. It is not the hash function associated with ImportedIdentity.target_kdf. If no hash function is specified, SHA-256 [SHA2] SHOULD be used. Diversifying EPSK by ImportedIdentity.target_kdf ensures" For the statement "If no hash function is specified", are we talking about the hash function "associated with the EPSK" or the one in "ImportedIdentity.target.kdf". This paragraph is trying to talk about both at the same time and I am struggling to unravel it. Section 6: The first paragraph seems to be largely repetitive of what was said in Section 4.1 paragraph 2 and re-addressed in section 7. While it might be good to restate the constraint, the words used are different and I found myself trying to figure out if it was adding any additional restrictions that were not previously stated. I think my primary feedback on this document relates to the constraint of not re-using PSKs. It feels like in an attempt to emphasize the importance, the point has been made numerous times in different ways with different terms and I think in this case, more clarity could be achieved with less words. e.g. "Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions" "Endpoints which import external keys MUST NOT use the keys that are input to the import process for any purpose other than the importer" "MUST NOT use the derived keys for any purpose other than TLS PSKs" "external PSK fed to the importer process MUST be associated with at most one hash function" "External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions" "this document requires that an EPSK is only ever used as an EPSK and not for any other purpose" "this requirement disallows direct use of the EPSK as a PSK in TLS 1.2" "avoid PSK re-use across KDFs while properly authenticating endpoints" "applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3" It is highly likely that some of these distinctions are important, especially because some of these are SHOULDs and some are MUSTs. However, my guess is that some of these phrases are saying the same thing in different words and for me they are obscuring the important distinctions. That could simply be my lack of domain knowledge. I appreciate the effort that folks put into topics such as these to ensure all of us can use the Internet securely. Hopefully some of my feedback will be useful. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
