[Rats] AD review follow-up on draft-ietf-rats-eat-20

[Roman Danyliw <[e-mail]>]

Hi Laurence!

Thank you for the very thorough response at https://mailarchive.ietf.org/arch/msg/rats/lPKyXpRSria9YGdTvZVxNlB08gk/ to my AD review of draft-ietf-rats-eat-19  at https://mailarchive.ietf.org/arch/msg/rats/50ZbUkhSrU1cgOLYkir3f1kKFiY/.

The vast majority of my feedback has been addressed or you have explained the underlying rationale for the current approach.  I have a few remaining comments, primarily around the new text in -20.  To make it easier to track this feedback, I’ve started this new message instead for providing further snipped inline comments in the previous thread.

** Section 4.2.1.  Thanks for the new Sections 4.2.1.1 and 4.2.1.2 to distinguish between the producer and consumer.  This clarifies my previous questions around the type byte.  The associated updates introduced the following text:

   Section 4.2.1.1
   In the unlikely event that a new UEID type is needed, it MUST be
   defined in a standards-track update to this document.

Two things:
-- This is roughly restating IETF policy.  As this document will be a published as a standard track RFC, lacking any other guidance, another standards track document would be the only way to modify it.  Are you sure it is needed?

-- The most flexible way to ensure future extensibility would be to create an IANA registry for these type values.  Assuming there needs to be very tight control, the registration policy could be standards action.

** Section 4.2.1.  On the topic of additional UEID algorithms, the following feedback came in to use v5 UUID (draft-ietf-uuidrev-rfc4122bis):

https://mailarchive.ietf.org/arch/msg/rats/YOWRagymNnmZZOoMznvMrJ0ELCw/

Does the WG want to add it?


** Section 4.2.14.  Are there Security Considerations around retrieval of DLOA from a given URI?

Thanks for adding the following text in -20:

    The retriever of a DLOA SHOULD follow the recommendation in [DLOA]	
    and use TLS to be sure the DLOA registrar they are accessing is	
    authentic.


A search of [DLOA] at https://globalplatform.org/wp-content/uploads/2015/12/GPC_DigitalLetterOfApproval_v1.0.pdf revealed only one place where TLS guidance is given:

==[ snip from [DLOA] ]==
5.2.3 Security Mechanisms
TLS security with server authentication SHALL be set up between the Management System and the DLOA

Registrar to ensure the Management System that it is talking to the right DLOA Registrar.

The DLOA Registrar MAY require authentication of the Management System to restrict access to some
DLOAs. In that case, TLS with mutual authentication SHALL be used.

Minimum TLS version 1.2 [RFC 5246] SHALL be used.
==[ snip ]==

[DLOA] seems to mandate the use of TLS between the management system (which I assume is the part of the RATS architecture checking the DLOA) and the Registrar.  With the use of the phrases “SHOULD follow”, the guidance in -20 appears to provide flexibility not afforded by [DLOA].  Is this divergence intentional? 


** Section 9.3.  Should there be a normative "MUST" about providing a freshness mechanism?

> author’s response to -20
> We were avoiding 2119 language in security considerations as security 
> considerations aren’t enforceable the same way protocol elements are. That 
> said, I don’t mind adding it.

> There is no comment on 2119 language in guide lines for writing security 
> considerations. RFC 9053 and 9052 don’t do it. TLS 1.3 does do it. COSE 
> counter sigs has one occurrence.

Many RFCs put normative language in the Security Considerations.  Doing so here wouldn’t be an outlier.  Please s/must/MUST/

** Section 9.4.  

[per -19]
   Since any COSE encryption will
   be removed by the receiving consumer, the communication of claim
   subsets to any downstream consumer should leverage a communication
   security protocol (e.g.  Transport Layer Security).

-- Should there be some mandatory equivalent made that the transport security properties should be at least as strong as the object security properties of the EAT?

[per -20] I didn’t see this addressed or didn’t understand the PR.

Thanks,
Roman