FYI, the -06 draft satisfies all my concerns. Thanks Brian Carpenter On 07-Oct-20 15:24, Brian Carpenter via Datatracker wrote: > 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. > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
