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

Hi Roman,

we tried to address all your comments. The are either reflected as a 
commit hash to the main of 
https://github.com/ietf-rats-wg/draft-ietf-rats-uccs/ or via direct 
replies in-line below.

The changes marked here with a “commit” number are both in the 
repository ([1], see [2]) and in draft-ietf-ietf-rats-uccs-09.

[1]: https://github.com/ietf-rats-wg/draft-ietf-rats-uccs
[2]: https://github.com/ietf-rats-wg/draft-ietf-rats-uccs/commits/main/

For the UCCS editors & authors,

Henk

On 02.02.24 23:16, Roman Danyliw wrote:
> 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.

Declarative statement in commit 09c97c1

The peers on each side of the Secure Channel need to decide which 
security properties they mandate.  One would expect that in many cases 
this will include confidentiality, integrity, and replay protection.
The semantics of the tag is that the UCCS conveyed via Secure Channel 
needs to be interpreted in a) the context of the security properties of 
that Secure Channel and b) creates the same peer's responsibilities as 
if equivalent object security would have secured the Claims Set.

> 
> ** 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.

We removed the object security examples in commit 3564e61
(To answer your question:
CMS: RFC 8769
X.509: Section 5 of draft-ietf-rats-msg-wrap)

> 
> ** 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.

Commit e497939:

OLD: channels.  As these are Claims, [RFC8392] is a suitable format.

NEW: channels.  As these are Claims, the Claims sets defined in 
[RFC8392] are a suitable format.

> 
> ** 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?

UCCS can be used in various contexts that are not RATS. With every 
context, there are different usage scenarios which have different (and 
very relevant!) security requirements. As the "stand-alone" use of UCCS 
without any instruction leaflet can result in severe security 
implication per context, this I-d comes well-phrased instructions how to 
use it in the RATS context. RATS applies in any usage scenario where 
RATS Conceptual Messages are conveyed. The use of tag 610 outside of the 
RATS context must come with additional instruction leaflets and security 
considerations.

We restructured Section 4 into a Section with the contents of what is 
now 4.1 and a Section with the additional scenarios in 4.2, 4.3.

The intro to the new section 4 now mentions that this is the only 
scenario for which UCCS is fully defined at this moment.

Commit 23d742d

> 
> -- 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.

(same commit)

---------------------------

All comments below on Section 4.1 (now Section 4) are addressed by 
commit 4d9605c

> 
> ** 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.

Indeed.  Clarified that this 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”?

We tried to point out that the assurance is only as good as the 
cryptography.  Rephrased.

> 
> ** 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?

Rephrased.

> 
> -- 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.

The quality of the authentication cannot be better than the quality of 
the sender. So some discussion of the tampering/hardening properties of 
the Attesting Environment is warranted.

> 
> ** 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?

No, this is specifically about how UCCS are different from CWTs.
This remark is intended to make explicit that CWTs are not governed by 
the Secure Channel context in he same way UCCS are.

> If not, why is discussing CWTs moving through the UCCS Secure Channel relevant here?

Just to prevent the potential confusion that a Claims Set transported 
within a CWT is treated the same as UCCS conveyed directly in the Secure 
Channel.

---------------------------

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

local inter-process communication
commit 15f3c03

> 
> ** 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

(we fixed that above)

> 
> -- 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.

The objective of 4.3 (now 5.2) is to discuss how authenticity does not 
necessarily lead to linkability.
It does not relax the authenticity requirement.
(E.g., DAA replaces the attester key with a group key, and something 
similar could be a use case for secure channels as well.)

> 
> ** 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”?

We added:

In order to be able to use the UCCS CBOR tag in another such scope,
the secure channel and/or the application protocol (e.g., TLS and the
protocol identified by ALPN) MUST specify the roles of the endpoints in 
a fashion that the security properties of conveying
UCCS via a Secure Channel between the roles are well-defined.

(This is intended to say that you can't just slap UCCS into a secure 
channel and assume you now have well-defined security properties.  Kind 
of obvious, but might be useful to remind people of.)

> 
> ** 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.

This is a security considerations section, which is not intended to be 
normative, but to supply additional information.

> 
> ** 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?

We added:

The remaining subsections of this section highlight some aspects of 
specific cryptography choices that are detailed in RFC 9053.

 > -- 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.

There is no implication that all these cryptography choices are 
available in every context.  (And we have removed the references to 
object security as a secure channel.)

> 
> -- 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?

UCCS is agnostic to this.

> 
> ** 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.

CWT claims sets are taken out of RFC 8392.  We didn't mean to focus on 
the claims defined there, but this is an area where common CDDL is 
lacking, so it is useful to supply this here.  More generally, UCCS uses 
the same "• CBOR Web Token (CWT) Claims" registry as CWT, and EAT added 
claims to that registry (not providing a syntactic distinction to other 
CWT claims).

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

It is another CWT claim.
RFC 8747:
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
It is not intended to provide a PoP key for the UCCS (which is not 
itself protected), but it provides a way to convey a key that can be 
used for further proof of possession of the attesting environment.

> 
> -- 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.

Yes.
Parts about JSON bindings do not use normative language, because UCCS is 
about CBOR claim sets.
This CDDL is designed to be useful in a mixed environment, based on 
requirements from EAT.

> 
> ** 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.

We cannot use TBD601 everywhere, because the formal languages break.
So we use 601 in examples and dependent CDDL
The IANA considerations section gets the registration part right.
We now reference and use CPA (draft-bormann-cbor-draft-numbers) here: 
commit cbcf8e0
(This reference would be a downref but vanishes during RFC editor 
processing, so it isn't.)

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

No, this Section is not intended to be normative. It is intended to 
provide an example of how something like a UJCS might look like that 
fits right into 4.18.2 of EAT.
commit c59c378

> 
> Regards,
> Roman
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats