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

[Michael Richardson <[e-mail]>]

Roman, we have published a -16 version as an intermediate reply to the 
issues.  Please see the diff at: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-architecture-16

We have closed a few issues with some pull requests, which I will list.
Some other issues we have decided to reply by email only.
I will move the issues which are still open to the end of the email.


On 2022-05-04 12:07, Michael Richardson wrote:
> 
>      > ** Section 8.1.
> 
>      > [Roman's comments on -13]
>      > In the spirit of inclusive terminology please use alternative phrasing
>      > for "man-in-the-middle attackers".
> 
> https://github.com/ietf-rats-wg/architecture/pull/405
> If only there was some document that proposed more precise, modern
> terminology here.

We have replaced this term with "active on-path attacker", but also 
having noted that the text makes the read/write/modify intention clear.

>> ** Section 10 - Freshness
> 
> https://github.com/ietf-rats-wg/architecture/issues/406
> 
>> 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.

As demonstrate by two replies from Eric and Thomas, and repeated 
discussions, we think that the WG does need it.    We agree that the 
level of detail is uneven, but that is because other design issues are 
not so easily abstracted.

>> ** Section 12 - Security Considerations
> 
> https://github.com/ietf-rats-wg/architecture/issues/407

This issue asks about why the Security Considerations seems silent on:

o Endorsers and endorsements?
o Reference values?

so, we noted that in fact the WG is constrained (up to next week) to 
dealing with these issues by charter, and that you noted that at least 
some documents that deal with these issues would have to wait for the 
recharter to finish :-)

We think that there may be other work that we could cite here, 
particularly around the third point:
"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?"

but, we don't think that there is anything significant we can say in the 
architecture document.  We reluctantly defined endorsers/endorsements 
and reference values, mostly so that we can rule them out of scope for 
this iteration of the architecture.  We did say that an attack on the 
appraisal policies (which includes RV and endorsements) is an attack of 
concern.

In the end, we don't think that there is a lot more to say here.

>> ** Section 12.1.2.1.  Editorial.
> 
> https://github.com/ietf-rats-wg/architecture/pull/408
> 
>      > [Roman's feedback on -13]
>      > The section title of "Integrity Protection" seems narrow given the
>      > content of this section.

We changed the title to _Conceptual Message Protection_

> 
> https://github.com/ietf-rats-wg/architecture/issues/409
> 
>      > ** 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?
> 
> https://github.com/ietf-rats-wg/architecture/issues/410

We made a slight text change to make the reference less prescriptive.
This is after all a non-normative, Informational, architecture document.


>
>> ** 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

>      > ** 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.
> 
> https://github.com/ietf-rats-wg/architecture/issues/411

This issue remains open.

> Roman Danyliw <[e-mail]> wrote:
>> ** Section 4.*.  Editorial.
>
> https://github.com/ietf-rats-wg/architecture/issues/403

This issue remains open.