[Rats] AD Review of draft-ietf-rats-architecture-15

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-rats-architecture-15.  This is a follow-up to the early review I did on -13 per  https://mailarchive.ietf.org/arch/msg/rats/V0tee4ohWoSzR6xGqu92GXuZneA/.  Issues previously mentioned against the -13 not mentioned here can be considered resolved -- Thank you!

** Section 4.*.  Editorial.  

[Roman's comments on -13]

-- Section 4.1.  In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean?
-- Section 4.2.  Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean?
-- Section 4.2.  Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean?

[Author's response] 
https://mailarchive.ietf.org/arch/msg/rats/zGTPhKrQfRfC14MTT_TKku5G5kY/

https://github.com/ietf-rats-wg/architecture/issues/357

[Roman's response on -15] 

I continue to hold the position that this language "Compare /xxx/ in RFC####" is not clear.  In the natural language sense, that phrase doesn't parse.  If the semantics are being taken from Section 2.6 of RFC4949, please explain that. However, it seems confusing to explicitly be listing antonyms (which RF4949 suggests is the meaning of the "Compare" notation).  In the case of a claim, is it an antonym -- isn't a claim here in fact similar to the one in Section 2 of RFC7519?

** Section 5. 

[Roman's comments on -13]

There is something foundational I am not following about this section.  The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1.  I'm not sure how to reconcile this discrepancy.  

Minimally, these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4.

[restated here but same feedback on -13]

-- Figure 5.  Shows the Attester consuming Attestation Results

-- Figure 5.  Shows the Attester producing Attestation Results

-- Figure 6: Shows Relying party consuming Evidence

-- Figure 6: Shows the Relying Party producing/passing Evidence

The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns."  I don't follow what is being illustrated in the context of RATS.  What is the takeaway for implementers or designers from this section?

[Author's response] https://github.com/ietf-rats-wg/architecture/issues/358

[Roman's response on -15] The above github comment addressed a few issues from the -13 review, but not this one.

** Section 8.1.  

[Roman's comments on -13]
In the spirit of inclusive terminology please use alternative phrasing for "man-in-the-middle attackers".

[Roman's comment on -15] 
I didn't see a response here.  I'd appreciate consideration on making this change.

** Section 10.  

[Roman's comment on -13]

I found the level of detail on this section on freshness out of place and inconsistent with the level of abstraction found in the rest of the test.  In most other section, generic interaction of roles, artifacts, their associated topologies, and high level security properties was noted.  This section delves into specific implementation choices.  In particular, is the WG sure that it needs all of the details of Section 10.3.  Even among all of the Section in 10.*, this stands out. It doesn't seem to provide enough detail to be create interoperability but goes beyond simply introducing the concept.

[Roman's comment on -15] Thanks for the extra paragraph to explain why this section is here.  I will confess that I still don't understand why these details are here and stand by my original comment.  It's much more than I would have expected for an architecture (especially considering the extra material in Section 16/Appendix -- 10 pages/almost 20% of the document is devoted to time issues).  If the WG feels like it needs it, I won't push back.  However, if this is the watermark of the level of detail, let's make sure that there is equal treatment for other security issues too.  See my feedback on Section 12.

** Section 12.  

[Roman's comments on -13]
I didn't come away from this section with a strong, consistent understanding of which interactions needs which security properties or what considerations are need for which roles.  Section 12.2 is at least clear on integrity, but it also makes vague allusions to other properties.  

-- Section 12.2  This section lists that there might be a need to support additional security properties and provides list (i.e., E2E encryption, DoS protection, authentication, etc.) .  What actionable guidance should be taken from this text?   How should one reason about those properties?

-- The overall Section 12 seems silent on:

o Endorsers and endorsements?
o Reference values?
o What is the implication of combining roles into a single entity as described in Section 3.4 and 6.  Does this lack of separation present any additional issues?
o Compositional devices per Section 3.3?

[Roman's comment on -15]
I didn't see any discussion on text changes in this section related to these comments.  I saw https://github.com/ietf-rats-wg/architecture/issues/367 which seemed to match this feedback, but the associated pull request seemed to fix an editorial issue.


** Section 12.1.2.1.  Editorial.

[Roman's feedback on -13]

OLD
So, this is why, in general, ...

NEW
Commonly,

** Section 12.2.  Editorial.  

[Roman's feedback on -13]
The section title of "Integrity Protection" seems narrow given the content of this section.

** Section 12.4. 

[Roman's feedback on -13]
 Since RFC5280 is being invoked here, is there an expectation that certificates in RATS would confirm to this profile?

** Section 16.  Can the thinking of this section be explained.  It seems out of place, and borders on being a solution.  The rest of this document talks about notional roles and architectures.  This text is focused on a particular nuance of message flow.  I'm wondering if we need it.  My thinking was to move this text to draft-birkholz-rats-epoch-markers.  As an aside, I did notice that draft-birkholz-rats-epoch-markers is using the amount of text on this topic in this document to motivate it's existence. 

My concern is that this text begs questions such as 

-- Why isn't a nonce or getting treatment in Section 4 as a consumer/producer if this is going to be first order item being exchanged?

-- Why isn't an Epoch ID Distributor depicted any role or architecture diagram?

-- (Not a comprehensive list) The flows depicted in the Examples don't align with the roles in Section 4.  Example 1 and 2, an Attester is shown here as consuming attestation results.  Example 5 shows a Relying Party producing Evidence.

Regards,
Roman