[Rats] review of draft-birkholz-rats-uccs-02

[Thomas Fossati <[e-mail]>]

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 don'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
          Kaspar Hauser 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 doesn’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 couldn't find anything relevant to UCCS there.

* Section 3.1
    * I don'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 don'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.