[Rats] Response to recent comments on EAT

[Laurence Lundblade <[e-mail]>]

If you are interested, here’s responses to MCR’s and Eliot’s comments. In addition there are PR’s for Kathleen’s and Eliot’s major comments that I’ve mentioned in other emails. Lots of PRs that we’ll be merging in the next few days for a new draft before the 114 cut off.

Really do appreciate the comments as they are making the document better! I know it takes a lot of work to make them.

LL




> On May 31, 2022, at 10:41 AM, Michael Richardson <[e-mail]> wrote:
> 
> I previously commented on eat-11, in which I suggested changes to the order
> of presentation, and wondered if the document was overly long in places.
> If you like, I can open issues directly, but not sure I have permission.
> 
> Here are my comments:
> 
> 1) I wonder if:
> RATS Attestation Evidence and Attestation Results.
> shouldn't just be:
> Evidence and Attestation Results
> since it follows a reference to RATS architecture.
> (I don't think that "Attestation Evidence" is a term from the Architecture document)
> "Attestation Evidence" is used repeatedly, and I think it could be shortened to Evidence.

Fixed:
https://github.com/ietf-rats-wg/eat/pull/198
https://github.com/ietf-rats-wg/eat/pull/220


> 
> 2) s1.1: _An entity is never a server or a service_
> I don't want to disagree with this statement, but as a negative statement in
> a series of positive statements it must be there because it is guarding
> against some confusion.  I suggest that it be moved to the end of the
> section, and that it be expanded to explain what the confusion is.
> Or that it be removed.

Improved:
https://github.com/ietf-rats-wg/eat/pull/199


> 
> 3) DEB is a poor choice of a TLA.  ".deb" are Debian packages.
>   Attestation is going to get tied up with SBOMs and other things, and the
>   cognitive overload of two TLAs will be a problem.
>   I don't think that the TLA helps understanding, I'd just go for Detached EAT.
>   (or... maybe... "Take Out"?  )
>   I'm sorry that I didn't notice that TLA before.
>   Also, "DEB" is not used consistently through the document, so maybe you
>   just don't need a TLA here.

Didn’t change the TLA


> 
> 4) s1.4.
> I suggest a new paragraph at:
> _EAT is also designed to carry Attestation Results._
> because it's important.

Fixed:
https://github.com/ietf-rats-wg/eat/pull/203/files


> 
> 5) _It is also possible that some claims in the Attestation Evidence will be
>    forwarded unmodified to the Relying Party in Attestation Results_
> 
> I think that _claims_ here refers to, what the terminology section says,
> which is a key/value pair, not a signed object.  But I had to check.
> I'm actually not certain if this sentence helps anything, and I'm worried it
> might confuse.

May have fixed this. Need to go back and re check (sorry I don’t have the PR handy)


> 
> 6) _There are no fixed rules for how a Verifier processes Attestation
> Evidence to produce Attestation Results_
> (...What is important is the Relying Party understand what the Verifier does and
> what its policies are. )
> 
> I don't think you mean to say this :-)
> The whole point of the Verifier is that it has a fixed and reliable set of
> rules that it follows, which the RP can... rely upon.  What I think you mean to say is that *This
> specification* does not establish any normative rules for the Verifier to
> follow.  They are a matter of configured policy.

Fixed: 
https://github.com/ietf-rats-wg/eat/pull/203/files


> 
> 7) _A claim named "nonce" is previously defined and registered with IANA for
>   JWT, but MUST not be used in an EAT. It does not support multiple nonces_
> 
> First, maybe "It" should be expanded to, "That previous definition does not
> support.."
> 
> Second, I was very confused about what the JWT claim name was in that
> section.  I looked ahead to 9.3.1, and it seems that this document is redefining "nonce".
> Probably, it should be "eat-nonce" or something like that.

Work still needed here.


> 
> 8) length of UEID:
> 
> _UEIDs are variable length. All implementations MUST be able to receive UEIDs
> that are 33 bytes long (1 type byte and 256 bits). No UEID longer than 33
> bytes SHOULD be sent._
> 
> Sounds a bit like Mr.Ford. You can have your model-T in any color, as long as it's
> black.   I had to read it three times.  May I suggest:
> 
> _UEIDs are variable length fields between X and 33 bytes in size.
> All implementations MUST be able to receive UEIDs that are up to 33 bytes
> long.
> 33 bytes accommodates 1 type byte and 256 bits.
> UEIDs SHOULD NOT be longer than 33 bytes.
> 
> (Since you write SHOULD, what are the exceptions)
> In looking for what X was, I see that type=0x01 accommodates 128-bit random
> numbers, so that means 7 bytes, so I think X=8.
> I see that type=0x02 allows for 6-byte EUI-48, so X=7.
> I'm unclear in JWT claims if the EUI-48, should be in printed form,
> or binary.  The document is very clear about IMEI situation.
> EUI-48 is 12 bytes ASCII, 17 if you include the "-" or ":".
> I think it doesn't matter, because it's up to the manufacturer, and the
> recipient (Verifier/RP) aren't supposed to interpret the contents... or are
> they?
> 
> _The consumer of a UEID MUST treat a UEID as a completely opaque string of
> bytes and not make any use of its internal structure_
> if that's the case, why do you need the type field? :-)
> 
> Can the SUEID be *identical* to the UEID?
> Or, MUST it be different for privacy reasons?
> 
> How are labels for the SUEID assigned? ("FDO")?

Improvements:
https://github.com/ietf-rats-wg/eat/pull/196
https://github.com/ietf-rats-wg/eat/pull/197


> 
> 9) I think that Security Level Claim should not be defined in this document.
> I think it will significantly delay the document in review.
> I have said this in another thread before, enough said.

Understood, but haven’t removed it.


> 
> 10) The Location Claim (location)
> I suggest that we find someone from the Google Android team to review this.
> They have specific reasons why they never attest this value, and permit
> devices to lie about location.

Have not talked to Google team.


> 
> 11) _The Boot Odometer Claim (odometer)_
> I think odometer is not the correct word.  "Count" would be correct.
> The device did not travel when it booted.

Fixed:
https://github.com/ietf-rats-wg/eat/pull/204


> 
> 12) 4.2.18. The Measurement Results Claim (measurement-results)
>   This claim is a general-purpose structure for reporting comparison of
>   measurements to expected Reference Values. This claim provides a simple
>   standard way to report the result of a comparison as success, failure,
>   fail to run, ...
> 
> This feels like something that should be accommodated with some kind of vendor
> specific extension process.  I don't think that the document or specification
> benefits from having a claim that is intentionally specific.
> 
> I would, in particular, not want it to be sent from the Verifier to RP, since
> I would have no idea what's inside it.

No changes made here.


> 
> 13) 4.3.1. Token ID Claim (cti and jti)
> Should it even be present?

I think it should. Improvements:
https://github.com/ietf-rats-wg/eat/pull/209/files


> 
> 14) I think that section 6 serves no purpose.
> _Endorsements and Verification Keys_
> _There is not yet any standard format(s) for an Endorsement._

There was a lot of interest when I presented this topic at a meeting a year or so ago. People asked me where I was going to publish it. So I don’t want to take it out

I will move it to an appendix, because I think that will help the document be cleaner and easier to read. It is a bit of an aside relative to the main body of what is defined by EAT.

Don’t have a PR for this yet.

> 
> 15) 7. Profiles
>  _This EAT specification does not guarantee that implementations of it will
>  interoperate. The variability in this specification is necessary to
>  accommodate the widely varying use cases. An EAT profile narrows the
>  specification for a specific use case. An ideal EAT profile will guarantee
>  interoperability._
> 
> "ideal"?  so, I have only a faint hope?
> I'm glad that you've collected all the issues in one place, but can this
> section be more proscriptive?

Lot’s of PR’s here. The main one to address this:
https://github.com/ietf-rats-wg/eat/pull/215


> 
> 16) 8.3. CBOR Interoperability
>   _This specification gives no blanket requirements to narrow CBOR
>   serialization for all uses of EAT_
> 
> Why?
> 
>   _One way to guarantee interoperability is to clearly specify CBOR
>   serialization in a profile document_
> 
> What are the other ways then?
> Perhaps we could just make some choices here, with clearly defined exceptions
> to the SHOULDs?
> Or is 8.3.1 complete here?
> s/must/MUST/?

Addressed indirectly:
https://github.com/ietf-rats-wg/eat/pull/218


> 
> 17) I did not review the CDDL.
> 
> 18) Section 9.2 feels like it is amending the IANA Considerations for CWT/JWT
>    Claims.  I think if we had some kind of sub-registry, we would clearly be
>    allowed to do that.  Given how things are, I'm not sure what we can do,
>    but maybe this section should be written more clearly as advice to the
>    Expert Reviews.

Agreed. Moving this to an appendix.
https://github.com/ietf-rats-wg/eat/pull/202

> 
> 19) I suggest that Privacy Considerations section and Security Considerations
>    sections be placed before IANA Considerations.  Many people stop reading when
>    they get to IANA Considerations.

Agreed. This seems to be the modern practice.


> 
> 20) the Security Considerations section is inadequate.
> 
> I think that the document should address freshness with reference to the Architecture
> document.  (no, not in the SC, but the SC needs to refer to it when talking
> about stale Evidence)
> It is probably the case that _Implicit Timekeeping using Nonces_ is often the
> right answer when EAT is transported over TLS.
> The nonce can be generated via a TLE Exporter, and I'd like to see this defined.
> Since TLS exporters need a string to hash through, that should go into a new section.
> I don't think this needs/should be left to the profile.
> 
> For other freshness mechanisms, the connection to the EAT Nonce perhaps needs
> to be made very very clear.  Like, hit them over the head.

Agreed, but haven’t done anything about it yet.



From Eilot Lear:

> 
> Minor:
> 
> Introduction:
> 
>    It is the use of this
>    key material that make the claims set "attested" rather than just
>    some parameters sent to the relying party by the device.
> 
> No.  Attestation is a claim of validity.  It is perfectly possible,
> and probably likely that many claims will be attested and not used.
> 
>    EAT is focused on authenticating, identifying and characterizing
>    implementations where implementations are devices, chips, hardware,
>    software and such.  This is distinct from protocols like TLS
>    [RFC8446] that authenticate and identify servers and services.  It is
>    equally distinct from protocols like SASL [RFC4422] that authenticate
>    and identify persons.
> 
> This paragraph is not well written.  EAT is an object that asserts the
> validity of a remote attestation claim object.
Have not addressed this.


> 
> 
> Appendix B:
> 
>    UUIDs seem to have been designed for scenarios where the implementor
>    does not have full control over the environment and uniqueness has to
>    be constructed from identifiers at hand.
> 
> I don't see the value of any of this commentary.  Either you know or
> you don't know.  There is no need for conjecture in such a document.
Improvement:
https://github.com/ietf-rats-wg/eat/pull/224


> 
> Is Section 4.4 somehow misplaced?  I'm not quite convinced what value
> it is adding in that section, or what is intended to be specified.
Reworked this section:
https://github.com/ietf-rats-wg/eat/pull/211


> 
> Section 6:
> 
>    There is not yet any standard format(s) for an Endorsement.  One
>    format that may be used for an Endorsement is an X.509 certificate.
>    Endorsement data like Reference Values and implied claims can be
>    carried in X.509 v3 extensions.
> 
> Define Endorsements or don't define Endorsements.  Don't half-define
> Endorsements. Just note that there is future work to be done
> somewhere.
Pulled in definition of Endorsement from RATS Architecture:
https://github.com/ietf-rats-wg/eat/pull/220/files

I will move section 6 to an appendix

> 
> Nits:
> 
> Abstract:
> 
>    To a large degree, all this document does is extend CWT and JWT.
> 
> This statement is just inaccurate and would add nothing in any case.
> Suggest you remove.
Didn’t address this (yet).


> 
> 
>    The document uses the term "entity" to refer to the target of the
>    attestation token.
> 
> Target or object?  A target implies something at which one aims.  An
> object is the entity upon which a subject acts through a verb.
“Target”. The term is used consistently in EAT and in RATS architecture. Object consistently refers to an EAT.


> 
>    The claims defined in this document are claims
>    about an entity.
> 
> Or more simply," the claims defined in this document describe an
> entity.”
Didn’t address this (yet).


> 
>    An entity is never a server or a service.
> 
> Neither server nor service is defined.  Don't go there.
Improved:
https://github.com/ietf-rats-wg/eat/pull/199


> 
> 
>    All claims in an EAT MUST use the same encoding except
>    where explicitly allowed.
> 
> That's better said, "... except where otherwise explicitly stated.”
Fixed:
(can’t find the PR at the moment)


> 
> Every instance of "CBOR encoded" or "JSON encoded" should be
> hyphenated.
Fixed the once instance this was not so:
https://github.com/ietf-rats-wg/eat/pull/208


> 
> Personal preference nit:
> 
> The English language requires capitalization only of proper nouns,
> acronyms, and the first letter of the first word of a sentence.  Legal
> documentation makes use of capitals so as to indicate a very specific
> meaning to phrase in what is generally highly convoluted language.  If
> you believe that your work is so convoluted that you need to use
> capitals, my suggestion is that you rewrite your work.  Otherwise,
> maybe use lower case letters.
This comment applies to the RATS Architecture document, not really to EAT. All the capitalization in EAT is for consistency with RATS architecture.

One small fix:
https://github.com/ietf-rats-wg/eat/pull/227


> 
> Section 4.1:
> 
>    In CBOR, the nonce is a byte string and every bit in the byte string
>    contributes to entropy.
> 
> This statement is a bit odd.  Can you show me a nonce in which some
> bit does NOT contribute too entropy?
Fixed:
https://github.com/ietf-rats-wg/eat/pull/225

> 
> 4.2.18
> 
> {#swevidence} should not appear in the text.
Fixed.
https://github.com/ietf-rats-wg/eat/pull/212

> 
> Section 4.3.2
> 
> If you are going to use the term "epoch" you have to describe when
> that epoch begins.  That has to be commonly understood between the
> parties.
Improvement:
https://github.com/ietf-rats-wg/eat/pull/214