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

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@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 