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

[Roman Danyliw <[e-mail]>]

Hi!

Thanks for the updates in -16 to -18.

I'm putting together multiple threads and github comments in one place below ...

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Tuesday, May 24, 2022 12:34 PM
> To: [e-mail]; Roman Danyliw <[e-mail]>
> Subject: Re: [Rats] AD Review of draft-ietf-rats-architecture-15
[snip]

> 
> On 2022-05-04 12:07, Michael Richardson wrote:

[snip]

> >> ** Section 5 -- Topological Patterns
> >
> > https://github.com/ietf-rats-wg/architecture/issues/404
> 
> We made a few small changes.
> You asked:
> 
> > Figure 5. Shows the Attester consuming Attestation Results Figure 5.
> > Shows the Attester producing Attestation Results
> 
> The text is pretty clear that this is not the case.
> We introduced a new paragraph break to make this easier to see, which is
> at:
> https://www.ietf.org/archive/id/draft-ietf-rats-architecture-16.html#section-
> 5.1-3
> 
> In the passport model, the Attester may well obtain the Attestation Results
> (the "passport"), and may well cache it for sometime and might use it
> repeatedly.  But these Results are signed in some way, and can not modified, so
> they aren't consumed or produced.  We debated putting a line through the
> Attester box, but due to the caching, we decided not to.
> 
> 
> > Figure 6: Shows Relying party consuming Evidence Figure 6: Shows the
> > Relying Party producing/passing Evidence
> 
> In this case, we changed the diagram to show the Evidence passing through the
> RP to get to the Verifier.  We discussed whether the RP could in fact cache that
> Evidence; whether there are cases where the Attestation Results might have a
> shorter lifespan than the Results.
> We think that this could sometimes be the case, but we felt that that the
> diagram would best be adjusted anyway.
> (Yes, we came up with different answers two what are apparently the same
> problem with the diagram)
> 
> https://github.com/ietf-rats-wg/architecture/pull/414/files

Thanks for clarifying.

What I'm getting from this text is that there is "producing" and "consuming" per Section 4.  I took those terms to be describing/constraining information flow -- what information can comes and go among the various architectural elements.  It appears that Section 5 is introducing a new behavior which is "accepting" (receiving but not processing) and "passing" (sending but not processing).  There also appear to be element specific behavior of "caching".

I see no conflict with these four behaviors.  My concern is that these nuances in behavior were not explicitly stated.  They should be.  Furthermore, just as certain architectural elements are defined by what they can produce or consume, I'm wondering if the same is true for the "accepting"/"passing" behavior?

> > -- The overall Section 12 seems silent on:
> >
> > 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?

[github said: https://github.com/ietf-rats-wg/architecture/issues/407]
==[ snip ]==
We need to acknowledge that there is a deep hole (not infinitely deep, but not trivial) where we need to look at integrity of all of the different platforms.
The way that the compositions are composed is a bit tricky, and the results are sometimes different than other people would naively assume.
Are there references here to other papers that we should include?
==[ snip ]==

I completely agree, that's why I mentioned it.  Composition is hard and can alter the security assumptions of the individual components and introduce emergent risk.

I don't think it can be solved generically.  However, we do need cautionary text here.  Perhaps:

NEW (roughly)

The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3).  Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still holds despite the lack of separation, and that emergent risk is not introduced.  The specifics of this evaluation will depend on the implementation and use case is out of scope for this document.

> ** Section 16.  Can the thinking of this section be explained.
[snip]

Thanks for explaining the thinking.  I do not agree that this text is appropriate given it's uneven treatment, but will support the desire of the WG to keep it.

One editorial matter that got introduced somewhere after -15, please make this a proper appendix.  It's currently " 16.  Appendix A: Time Considerations", that is, Section 16 with word "appendix" in the title.  Perhaps this is a rendering issue.


Regards,
Roman