Brian, thanks for your review. Authors, thanks for your responses. I entered a No Objection ballot. Alissa On Thu, Dec 3, 2020, at 4:29 PM, Brian E Carpenter wrote: > 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 > > > > _______________________________________________ > 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
