Subject: [Rats] WGLC Review of draft-ietf-rats-architecture-07

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 18 Nov 2020 17:31:22 +0000

As part of WGLC, I have reviewed draft-ietf-rats-architecture-07, and
believe it an excellent document.  Below are three minor comments and five
nits which I believe are worth addressing.  

Major Comments
-----------------------
None

Minor Comments
-----------------------
Section  4:  General Comment  (this comment could also apply to Section 12)
It is up to the Relying Party to evaluate the Verifier.  And not all
Verifiers should be seen as equivalently trustworthy.  Additionally, any
particular Verifier might be able to provide a consistent level of certainty
in the "Attestation Results".  This is because the capabilities of the
Attesting Environment will vary.   This section does not hint at the varying
levels of certainty in the "Attestation Results" based on the varying
quality and quantity of available Evidence of different types of Attesters.
I am not sure if this truism belongs in this section.  Or if this truism
belongs in the document at all.  But without having this nuance being
described somewhere, it could leave the perception of a higher level of
confidence in the Appraisals being from a deployable RATS architecture made
than might necessarily be warranted.    Note that this issue is also alluded
to in Section 7.4 and Section 12.  But neither address things like whether
Attestation Result values should provide a minimum level of confidence
regardless of the type of Attester being evaluated.
In the end, I am fine if nothing changes in the document as a result of this
comment, but I wanted to have the authors consider whether this is worth a
statement or two.

Section  5.1
Current Text: If the Attestation Result was a successful one, the Attester
can then present the Attestation Result to a Relying Party, which then
compares the Attestation Result against its own appraisal policy.
Proposed Text: If the Attestation Result was a successful one, the Attester
can then present the Attestation Result (and possibly additional Evidence)
to a Relying Party, which then compares this information against its own
appraisal policy.
Alternative way to address comment: In Section 5.3 is a discussion on
"Combinations".  A final sentence or paragraph could be added on another
example of a combination where the Attestation Result from a Passport Model
can be a form of Evidence coming into a background check model.
Rationale #1: There are multiple statements in Section 5.1, including the
diagram which do not show additional Evidence allowed to be included as part
of the passport model.  We need at least one statement within Section 5
which shows this to be a valid scenario.  I do not think Figure 7 covers
this option sufficiently.  (Note: this goes back to previous email list
discussions showing that a even a government issued passport is stamped with
supplemental information as people transit country borders.)
Rationale #2: Section 8.3 on Attestation Results do not reference
"Combinations", nor that Attestation Results can be a type of Evidence.
Rationale #3: Section 16.2 includes a Nonce2 as supplemental evidence as
part of the passport model diagram. 

Section  16.3
The notational convention for the use of ' (i.e., prime) after timestamps is
not described.  E.g. time(HR'_v).   I think its meaning can be figured out
by the diagram.  But it might be worth making it an explicit notification
convention.  And other subsequent documents might want '' as well.

Nits:
------
Section 2: Reference Value Provider
Currently: ...Reference Values help Verifiers appraise the authenticity of
Evidence
Proposed: ...Reference Values help Verifiers appraise Evidence to determine
if only known and acceptable claims have been recorded by the Attester    

Section  3.6:
Currently: One significant problem is malware that holds a device hostage
and does not allow it to reboot to prevent updates from being applied.
This is a significant problem,
Proposed: There is a class of malware that holds a device hostage and does
not allow it to reboot to prevent updates from being applied.   This can be
a significant problem,

Section  4:
Currently: pppraisal policy
Proposed: appraisal policy

Section 11:
Currently: as well as any users the device is associated with.
Proposed: as well as potentially any users of the device.

Section  12.1
Currently: Key Material
Proposed: key material

Thanks,
Eric