Draft: draft-ietf-rats-uccs

Commentary: JWT has this null cipher construct for unsigned  claims - sets . It seems wasteful and ill conceived to me especially in light of UCCS . EAT is successfully defining claims in both  and CBOR . Why not make UCCS in to a CDDL definition of the basic claims in CWT and JWT and define simpler way to do unsigned claims in JSON format ? You already have all the security considerations . 
 I believe the spirit of this issue is now covered in the CDDL . Closing . 
 Lest we forget : Note : although this was a review for birkholz-02 , I do n't think the points raised have been addressed in birkholz-03 ( which I guess it 's equivalent to rats-00 ) . 
 Can this be closed now ? 
 Yes . I have some more comments but I will provide them in another review .
Mailing list commentary: Dear draft - birkholz - rats - uccs-02 authors , I have reviewed your draft and here 's a list of comments . The general impression is that the content should be streamlined and reorganised a bit . To that purpose , I am adding a few suggestions according to my personal taste that you may find completely rubbish . As a reviewer I think I need to exercise this privilege though :-) Let 's go . Section 1 " the integrity protection mandated by RFC 8392 " is " mandated " the right word ? What about alg : none ? " COSE provides - amongst other things - the integrity protection mandated by RFC 8392 and optional encryption for CWTs . " I think the other important security property that COSE provides is it identifies the principal of the asserted claims Another relevant feature is that COSE provides the security properties end - to - end , not just in transit . " Under the right circumstances " What are these " right circumstances ? " Please provide a precise characterisation ( in place , or as a fwd ref ) . " If a mutually Secured Channel is established between two remote peers , and if that Secure Channel provides the correct properties , it is possible to omit the protection provided by COSE , creating a use case for unprotected CWT Claims Sets . " I am now reading the third para and I do n't know yet what these " correct properties " are . The impatient reader - like yours truly - is going to be scratching his beard at this point :-) " Consequently , in a well - defined scope , it might be acceptable to use the contents of a CWT without its COSE container and tag it with a UCCS CBOR tag for further processing " Please do not suggest this , it 'd have the effect of changing the semantics in a surprising way - from something with an associated principal to something that is completely lost , the of RATS . If you need to forward " naked " claims e.g. , as you do in the verification pipeline once you have checked the signature - you just do that . No need for extra tagging : pass the CBOR map on and the calling site will know what to do with it . Comment : the intro seems to never get to the point . What I 'd like to see here is " the why of UCCS " . A couple of lines should be enough : Rationale for using UCCS Basic principle of using resources parsimoniously : when RATS roles have a pre - existing security association they can reuse it to implicitly sign their conceptual messages ( There is also the case in layered attestation of an attesting environment that does not have a signing key . In this case the protection is delegated to the outer attesting environment . The expected output is a nested EAT with a UCCS submod . However , this case does n’t need further discussion because it falls back to the usual signed EAT . ) Section 2 The motivation could be made less obscure The title seems partially incorrect : in fact , the requirements are absent ( the reader is forwarded to " following sections " ) Comment : I 'd just remove this section and merge whatever is relevant , if anything , into the intro . Section 3 " The handshake protocol establishes the authenticity of one of both ends of the communication . " Typo : one of both = > one or both s / authenticity / identity/ " Analogously , the considerations discussed in Sections 2.1 , 3.1 , and 3.2 of RFC 8725 apply to the use of UCCS as elaborated on in this document . " Are these references really applicable ? I have followed the ref and I could n't find anything relevant to UCCS there . Section 3.1 I do n't understand the SHOULD in " the Verifier and the Attester SHOULD mutually authenticate when establishing the Secure Channel " . If there are valid reasons to make the behaviour discretionary , it 'd be useful if they were stated explicitly . Last para : I do n't understand the use of the term " endorse " here . ( I might be confused by the special meaning it is given in the RATS architecture document though . ) Section 3.2 " A Secure Channel which preserves the privacy of the Attester may provide security properties equivalent to COSE " Could you please provide an example of such privacy - preserving secure channel ? You mean running an attestation protocol over Tor ? I am slightly confused about the intended meaning of the second part of the sentence : which COSE properties are relevant here ? Comment : what I 'd have liked to see here is a crisp " applicability statement " , answering the simple question : Under which circumstances the signature " recycling " is warranted , i.e. it does not degrade the security assumed by the RATS architecture ? For both Evidence and Attestation Result The signing key that identifies the " secure wrapping " entity ( e.g. , the secure transport endpoint ) is or can be linked directly to the same key that would have signed the attestation Evidence / Attestation Result , were it encoded as " proper " CWT . The robustness of the key material and algorithms employed in lieu is comparable ( i.e. , use modern secure protocols with recommended cipher suites ) For further applicability considerations , see the bottom of Section 7.4 of I - D.ietf - rats - architecture Also , I think it 's important to state the caveats that apply , e.g. : the different protection span temporal the cryptographic protection provided by a secure channel is ephemeral Spatial The cryptographic protection provided by a secure channel is only effective inside the perimeter of the tunnel As a corollary : when UCCS arrives at destination , it MUST be consumed by a trusted entity and never forwarded outside the TCB Also , compared to CWT , UCCS is vulnerable to an active MitM who can distort the Evidence / Attestation Result modifying , adding , or removing claims at will Section 5 I have followed the ref and it 's unclear to me why the security considerations of RFC8392 apply here . Maybe be more specific about what exactly can be transplanted from there . That 's all . Cheers ! IMPORTANT NOTICE : The contents of this email and any attachments are confidential and may also be privileged . If you are not the intended recipient , please notify the sender immediately and do not disclose the contents to any other person , use it for any purpose , or store or copy the information in any medium . Thank you .
Paragraph (version A):
When UCCS emerge from the Secure Channel and into the Verifier, the
security properties of the Secure Channel no longer apply and UCCS
have the same properties as any other unprotected data in the
Verifier environment.  If the Verifier subsequently forwards UCCS,
they are treated as though they originated within the Verifier.
Paragraph (version B):
When UCCS emerge from the secure channel and into the Verifier, the
security properties of the secure channel no longer protect the UCCS,
which now are subject to the same security properties as any other
unprotected data in the Verifier environment.  If the Verifier
subsequently forwards UCCS, they are treated as though they
originated within the Verifier.
Paragraph (version A):
The security considerations of RFC8949 apply.  The security
considerations of RFC8392 need to be applied analogously, replacing
the role of COSE with that of the Secured Channel.
Paragraph (version B):
The security considerations of RFC8949 apply.  The security
considerations of RFC8392 need to be applied analogously, replacing
the function of COSE with that of the secured channel.
Paragraph (version B):
Evidence in a UCCS conveyed in a secure channel generally cannot
be used to support trust in the credentials that were used to
establish that secure channel, as this would create a circular
dependency.