Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-tls-external-psk-importer-05 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-tls-external-psk-importer-05 Reviewer: Brian Carpenter Review Date: 2020-10-07 IETF LC End Date: 2020-10-15 IESG Telechat date: Summary: Ready with issues -------- Issues: ------- >1. Introduction > > Applications SHOULD provision separate PSKs for TLS 1.3 and prior > versions when possible. I think that "when possible" could easily be used as a loophole by a lazy implementer. ("Impossible, because I'd have to refactor my code.") Since presumably this rule is to avoid all risk of a "related output" cryptanalytic vulnerability, why weaken the RFC2119 definition of SHOULD? The formal definition of SHOULD is stronger, with "the full implications must be understood and carefully weighed before choosing a different course." So I suggest simply deleting "when possible". >6. Incremental Deployment > > Recall that TLS 1.2 permits computing the TLS PRF with any hash > algorithm and PSK. Thus, an EPSK may be used with the same KDF (and > underlying HMAC hash algorithm) as TLS 1.3 with importers. However, > critically, the derived PSK will not be the same since the importer > differentiates the PSK via the identity and target KDF and protocol. > Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS > 1.2, and thereby avoid cross-protocol collisions. Note that this > does not preclude endpoints from using non-imported PSKs for TLS 1.2. > Indeed, this is necessary for incremental deployment. I read this three times and I have to ask whether "TLS 1.2" is really what you want in the penultimate line. Nits: ----- >4.1. External PSK Diversification ... > ImportedIdentity.target_protocol MUST be the (D)TLS protocol version > for which the PSK is being imported. For example, TLS 1.3 [RFC8446] > and QUICv1 [QUIC] use 0x0304. As far as I can tell, [QUIC] doesn't specify this, but draft-ietf-quic-tls does specify that QUICv1 uses TLS1.3. So the phrasing is a bit misleading. Maybe: For example, TLS 1.3 [RFC8446] uses 0x0304, which will therefore also be used by QUICv1 [QUIC-TLS]. Are all the RFC2119 terms capitalised when required? For example, there are lower case 'may' and 'must' in the last paragraph of section 4.1 (External PSK Diversification). I couldn't determine whether they were intended to be normative. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
