[Rats] AD review of draft-ietf-rats-uccs-08

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-rats-uccs-08.  Thanks for this document.  My feedback is below:

** Section 1.1.  The minimally required security properties of the Secure Channel seem unclear.  It seems to be defined in three ways:

-- The NIST definition is cited to say that it would be a channel that provides confidentiality, integrity, replay protection and mutual authentication.  

-- Via examples of PCIe IDE, TLS or CMS and X.509

-- Via the statement of “in specific cases, the Secure Channel as defined here does not itself provide mutual authentication”

Does the mean that the security properties of the “Security Channel” as defined here must be “confidentiality, integrity, replay protection”?  Could a declarative statement on the security properties please be made.

** Section 1.1.  
     Examples include
      conveyance via PCIe (Peripheral Component Interconnect Express)
      IDE (Integrity and Data Encryption), a TLS tunnel, or other object
      security than COSE, such as CMS or X.509 v3 certificates. 

If possible, can a pointer please be provided on how to pass CBOR via CMS or X.509.

** Section 2.  Editorial.
  As these are Claims, [RFC8392] is a suitable format.   

That statement struck me as odd since the whole premise of this document is that RFC8392, the CWT, can’t be reused and it’s being decomposed and re-bundled here.

** Section 4.  How is this section to be used?

-- The title says “UCCS and Remote Attestation Procedures (RATS)” .  Does it not apply if not in the RATS context?  How does one normatively know that “RATS” applies?

-- Are the sub-sections normative?  Section 4.1 uses RFC2119 language which suggests normative.  However,  Section 4.2 is high-level prose and not sufficiently specified to be interoperable.

** Section 4.1
   As a minimum requirement in the scope of RATS Claims, the receiver
   MUST authenticate the sender as part of the establishment of the
   Secure Channel.  Furthermore, the channel MUST provide integrity of
   the communication between the communicating RATS roles.  If data
   confidentiality [RFC4949] is also required, the receiving side MUST
   be authenticated as well; this can be achieved if the sender and
   receiver mutually authenticate when establishing the Secure Channel. 

This text seems to be suggesting that confidentiality might not be provided in the Secure Channel.  However, the definition in Section 1.1 seems to suggest it is a requirement.

** Section 4.1.
   A Secure Channel established or maintained using weak cryptography
   may not provide the assurance required by a Relying Party of the
   authenticity and integrity of the UCCS.

How could “weak cryptography” be used in a Secure Channel if the security considerations and associated algorithms should be “similar to COSE”?

** Section 4.1.
   Where the security assurance required of an Attesting Environment by
   a Relying Party requires it, the Attesting Environment SHOULD be
   implemented using techniques designed to provide enhanced protection
   from an attacker wishing to tamper with or forge UCCS.

-- I had trouble following this guidance.  The first clause says “where the security assurance required of the attestation environment” suggesting something is required.  However, the second clause then says “the Attestation environment SHOULD”.  SHOULD implies it is not mandatory.  How can a mandatory need be satisfied in an optional way? 

-- What is the relationship between the Attestation Environment and the UCCS?  I ask because there appears to be an optional (SHOULD) to prevent tampering or forgery of the UCCS.  However, the Secure Channel defined in Section 1.1 seems to suggest that integrity and replay protection is mandatory.

** Section 4.1
   As with EATs nested in other EATs (Section 4.2.18.3 (Nested Tokens)
   of [I-D.ietf-rats-eat]), the Secure Channel does not endorse fully
   formed CWTs transferred through it.

I am confused as to why there is discussion about a Secure Channel and CWTs.  Should this be UCCS?  If not, why is discussing CWTs moving through the UCCS Secure Channel relevant here?

** Section 4.2.  Editorial.  Please expand “local IPC”

** Section 6.
   The security
   considerations of [RFC8392] need to be applied analogously, replacing
   the function of COSE with that of the Secure Channel. 

If all of the Security Considerations of RFC8392 apply, then there is an authenticity requirement for the Secure Channel.  RFC8392 says “it is not only important to protect the CWT in transit but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT.”  Such a requirement conflicts with:

-- the definition Secure Channel in Section 1.1 seems to indicate that authenticity might not always be provided

-- the Privacy Preserving channel of Section 4.3 seems to explicitly suggest that there “receiver cannot correlate the message with the senders of other received UCCS messages “ which seems to be the opposite of authenticity.

** Section 6.
The UCCS specification -- and the use
   of the UCCS CBOR tag, correspondingly -- is not intended for use in a
   scope where a scope-specific security consideration discussion has
   not been conducted, vetted and approved for that use. 

Can this guidance be clarified to explain who is supposed to do what?  Who is supposed conduct the “scope-specific security consideration discussion”?  Who is “approv[ing] use”?

** Section 6.1 – 6.4.  How is the reader supposed to interpret this section?  Is it normative?  Section 4.1 reminds us that “For the purposes of this specification, the mechanisms used to establish a Secure Channel are out of scope.”  However, this section appears to go in depth on the properties of that Security Channel mechanism.

** Section 6.2, 6.3. and 6.4.  Abstractly, the guidance in this section is clear.  As cited, it appears to be coming from different places in RFC9053.  

-- From an editorial perspective, is the WG confident it needs to reproduce this guidance here?

-- From the perspective of an implementor, how would one use this guidance?  Section 1.1 provides illuminating examples of Secure Channels: TLS, CMS, X.509, PCIe IDE.  Is there a sense of which Secure Channels one would apply this too?  I ask because I’m not sure how any of these are relevant for X.509.  Per TLS, applying this guidance doesn’t seem straightforward.  I don’t know much about PCIe IDE but I think it only support AES-GCM.

** Appendix A.  I observe that in the body of the text there is no discussion of what claims are permitted in a UCCS.  Is anything possible?

** Appendix A.  Excuse my rough understanding of CDDL.  

-- Why did the WG decide to use the CWT claims in Figure 1 of RFC8392?  These don’t seem germane to the RATS use case? I was under the impression that RATS intended to use UCCS to describe evidence via CWT claims.  I don’t see that here.

-- What role does CWT-cnf play?  This appears to be primitives to provide object security which UCCS is not intended to do?

-- My read of this CDDL is that there is JSON hooks included with the JC<> construct.  This JSON binding isn’t explained any place else.

** Appendix B.  What is the original of the 601 tag?  From https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml that looks unassigned.  I have observed the IESG entering DISCUSS ballots on instances were examples of unallocated values are used.  Minimally, add an note to the RFC Editor with instructions to replace this value with the allocated ID.

** Appendix C.  Did this section just invent the concept of UJCS?  Is this normative?

Regards,
Roman