Re: [Gen-art] Genart last call review of draft-ietf-tls-external-psk-importer-05

[[e-mail]]

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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/gen-art
> > 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art
>