[Rats] Re: review of S6, S7 (intro) and S7.1 of draft-ietf-rats-reference-interaction-models-11

[Thomas Fossati <[e-mail]>]

hi Henk,

Apologies for the radio silence.

On Tue, 8 Oct 2024 at 22:02, Henk Birkholz <[e-mail]> wrote:
> On 03.10.24 17:11, Thomas Fossati wrote:
> > -------
> > Scope of work. The document should state more clearly what is being
> > delivered, i.e.: three interaction models (IM) between Attesters and
> > Verifiers (and, optionally, RPs) involving Evidence and Attestation
> > Results. There could be other IMs that this document does not cater
> > for. While I agree these same IMs may also apply to other roles and
> > other conceptual messages, at this point, this is still TBD and I
> > think the document should refrain from making this claim. (I am saying
> > this because it's repeated in more than one place.)
>
> Ah. No there is no assumption that this is a list of complete
> interaction models. The document currently is pretty exhaustive and that
> is something to the extend that should probably be put in writing.
>
> The text now consistently highlights that:
> * the document explicitly illustrates conveyance of Evidence for
>    boot-time integrity

Question: Why is IMA-like stuff not in scope?

> * the models illustrated are not an exhaustive list

OK

> * can be applied to any data/CM flow depicted in RFC9334 Section 3

That is the kind of claim that I'd like to avoid.  Until proven by an
existing, well-defined IM, why not erring on the side of caution -
i.e., say "may" rather than "can", and add that it is expected that
other documents will provide those?

> The change is reflected in commit 6bcfe7e.

Thanks, see PR comments inline.

> > -------
> > S7.1: Use of refValues in appraiseEvidence is a bit misleading:
> > Endorsements and Policy are also input.  Besides, the definition of
> > refValues is not in line with 9334 (according to the definition,
> > Endorsements are refValues too.)  I suggest defining a verifierInputs
> > instead, and describe it as containing RVs, Endorsements and Appraisal
> > Policy for Evidence.
>
> Yes, reiterating all CMs is very annoying and that was actually a
> misleading omission, I think.
>
> Please find the newly minted 'verInputs' as a mandatory "catch all"
> information element that now is manifested with commit 6c0d5c5.

Awesome.  See PR comments inline.

> > -------
> > S7.1: This bit doesn't sound completely right:
> >
> > "In the Challenge/Response model, the Handle is composed of qualifying
> > data in the form of a practically infeasible to guess nonce, such as a
> > cryptographically strong random number."
> >
> > What about epoch markers?
>
> Some parts still show the age of this document. Of course Epoch Marker.
> They are already mentioned more up front where the information element
> Handle is described, but it does not hurt to point them out here again.
> More comprehensive text comes with commit 1bd4930.

Nice!

> > -------
> > S7.1: Using Key IDs to select which AE's Evidence a Verifier wants to
> > collect is a tad too strict.  I understand the motivations, but I
> > don’t think key IDs are the right building block/abstraction to model
> > an "AE selector" that works in all cases.  The same function could be
> > implemented using media types or some other
> > sub-attester/layer-specific identifier obtained with some TBD
> > discovery mechanism.  It’s an implementation choice. I suggest making
> > the Attestation Key IDs information element less concrete/more
> > encompassing, for example replacing it with an "Attesting Environment
> > IDs" and explaining that it could be implemented using key
> > identifiers, media types and all other sorts of
> > attestation-scheme-specific identifiers.
>
> I tend to agree. The corresponding information element is now about
> Attesting Environment IDs instead of Attestation Key IDs. With that
> comes the new short form of the IE that is: 'attestEIDs'. The text
> change manifests as 586aa3c.
> The corresponding diagram changes (which I overlooked because there was
> an inconsistency in the abbreviation usage...) is captured separately in
> commit b0526f7.

Awesome, thanks.

> > -------
> > S7.1: The interaction between AE selection (via key IDs) and Claims
> > selection during Evidence creation doesn’t look right.  ISTM that
> > Claim Selection is per AE (i.e., per key ID) rather than being
> > globally applicable - as it’d seem from the description.
>
> This feedback triggered a rather scattered rewrite of Section 7.1,
> including some more instances of "Attestation Key IDs"-related fixes.
> Please find and check the results in commit 6f67458.

OK

> > -------
> > S7.1.1.1: In passport mode, is Evidence a mandatory information
> > element from Attester to RP? Or may Attestation Results be sufficient?
>
> The Attester only produces Evidence and the illustration of models in
> this I-D also uses Evidence conveyance as an example. For the sake of
> versatility, it could be considered prudent to include one or two
> sentences to highlight that option, but AR originate from the Verifier
> and not from the Attester (are thereby cached by the Attester and
> recentness demonstration via nonce becomes less useful, I think). Would
> you be willing to whip together a suggested change in the PR?

I will, not sure I can do that shortly though.  Let's take this offline maybe.

> > -------
> > S7.1.1.2: In background-check, it could also be that the RP opens a
> > session to the Verifier to get the handle, which is then forwarded to
> > the Attester.
>
> While this is true, this scenario also comes with new questions:
>
> I am uncertain how the trust model would look like in your scenario. Why
> would the Attester trust the Relying Party? Is there an existing trust
> relationship between the Attester and the Verifier? How to prevent
> replay attacks when retrieving a handle (e.g., you could replay a handle
> potentially - and to require a handle to retrieve handle which would
> then require a handle to retrieve that handle which...  is a turtles all
> the way down scenario that has to be prevent with some additional
> measures, such as massive states/lists or something equally thorough)?
>
> Sounds a bit like specific technical solution to me and not in scope
> here? Maybe I am wrong, though. Could you elaborate if I am missing
> something?

The challenger must be authenticated.  Therefore, in this interaction,
the Attester needs to trust the RP.  The rest of the trust
relationships would not need to change I guess - e.g., as usual, the
RP needs to trust the Verifier.

cheers, thanks!