Re: [Rats] comments on draft-birkholz-rats-architecture-02

[Henk Birkholz <[e-mail]>]

Hi Jürgen,
hi Hannes,

I'll add some of the reasoning to most of the items below:

On 02.10.19 11:11, Hannes Tschofenig wrote:
> Clicked the enter key accidentally and sent the mail far too early....
> 
> Below is another try:
> 
> -----Original Message-----
> From: Hannes Tschofenig
> Sent: Mittwoch, 2. Oktober 2019 11:01
> To: Schönwälder, Jürgen <[e-mail]>; [e-mail]
> Subject: RE: comments on draft-birkholz-rats-architecture-02
> 
> Hi Jürgen,
> 
> Thanks for your review. Looks of great questions.
> Below is my take on it.
> 
> -----Original Message-----
> From: RATS <[e-mail]> On Behalf Of Schönwälder, Jürgen
> Sent: Mittwoch, 25. September 2019 16:18
> To: [e-mail]
> Subject: [Rats] comments on draft-birkholz-rats-architecture-02
> 
> Hi,
> 
> I am rather new here to please forgive my ignorance. I thought I start by reading the architecture document. Some of my questions may just show my ignorance but then this is what happens if you get fresh reads...
> 
> - What is 'normative guidance'?
> 
> [Hannes] Should just be 'guidance' but on the other hand an architecture document shouldn't provide guidance.
> I guess we have to change the sentence altogether from "
> In general, this document
>     provides normative guidance how to use, create or adopt network
>     protocols that facilitate RATS.
> "
> To:
> 
> "
> This document defines terminology and describes the architecture of the remote attestation procedures (RATS) standardization work in the IETF.

Thank you Hannes - the new phrasing is more to the point.

The higher level goal is of course to enable readers to build complete 
remote attestation procedures that are composed out of Princapls that 
are composed of... and so on. That's not a good start for the text 
though, especially as we tried to serialized the definitions in an order 
that was simpler to understand than before.

In general, a bit more redundancy to that respect does not hurt, I 
think. See next point.

> "
> 
> - Would it not make sense to also define the terms introduced in 1.1?
> 
>    - Claims
>    - Evidence
>    - Known-Good-Values
>    - Endorsements
>    - Attestation Results
> 
>    Perhaps section 1.1 should be folded into section 2 so that all
>    terminology is defined in one place. What about terms such as
> 
>    - Attester
>    - Verifier
>    - Asserter
>    - Relying Party
> 
> [Hannes] I agree with your observations. Section 1.1 should be merged with Section 2 and these additional terms should be added.

The intent of 1.1 is... well to give a quick overview. Merging it with 
section 2 would shift that meaning and would render it to be just a 
terminology definition. Actually, we thought we were providing a concise 
definition in 1.1 beforehand (detailed definitions are in section 4), 
but the goal is to address new readers, such as you, and that apparently 
did not work out so well :)

So we will have to have another stab at this.

Is it a good approach to define RATS messages (the first block you 
highlighted) not only in the section RATS Messages (4.3.2) but in a 
terminology section, too? I am uncertain how much redundancy is useful. 
Jürgen, would that have helped?

> 
> - What are 'architectural constituents'?
> 
> [Hannes] Should be replaced with 'entities'

There were always multiple opinions about this. Maybe defining 
architectural constituents would be better? What we meant here are the 
instantiated architectural components that make entities a part of a 
RATS architecture, i.e. messages/interactions, roles and principals - 
which explicitly do not include e.g. persons or organizations.

> 
> 
> - Separation:
> 
>     A Computing Environment with the capability of remote attestation:
> 
>     o  is separate from other Attested Computing Environments (about
>        which attestation evidence is created), and
> 
>    Does it always have to be separate? Is there an architectural
>    requirement for these to be separate?
> 
> [Hannes] A figure would help here.  In the model we use at Arm with TrustZone for v8-M the computing environment is separate from the attesting computing environment.
> Since the term separate is not further elaborated I doubt there is a problem.

Yes, a figure would have helped and will help in the future.

> 
> - If you read this document for the first time, it is difficult to put
>    the various terms together in your head. Figure 1 helps but it comes
>    a bit late, it would help if it would be shown early. It would have
>    helped me if all key terms are defined upfront followed by a Figure
>    explaining relationships or interactions before the discussion of
>    details starts.
> 
> [Hannes] I have to agree with you. Maybe it helps to move Figure 1 up or to re-arrange other sections.

Okay - the question is, where to put it. Probably in the overview 
section 1.1?

> 
> 
> - Not sure this helps me understand things:
> 
>    (e.g.  Prinicipals that are Supply Chain Entities)
> 
> [Hannes] Maybe a complete example would help.

Yes, there is the

> 
> - What are Appraisals?

Appraisal is the activity (function) that a Verifier conducts. We had a 
clearer definition of Creation of Evidence (via the Attester) , 
Conveyance of Evidence (via an Interaction), and Appraisal of Evidence 
(via a Verifier) in the last version. Due to the refactoring that got 
lost too much, as I see now.

Maybe reintroducing that in the overview will help, too?

> - Evidence

A RATS message defined in 4.3.2

> - Endorsements

Also a RATS message defined in 4.3.2

> 
> [Hannes] If it makes you feel better I have also been wondering why the attestation community uses so complex terms.
> I yet have to find out how to make it simpler (or how to describe it better).

Correct terminology is quite of the essence here as, for example, sets 
of claims and sets of evidence are messages with different meaning. 
Simplification (or better... abstraction) is the thing we did the most 
in since the BoF. I am rather certain that we cannot simplify without 
losing meaning, currently. But we most certainly can work on the 
description part.

> 
> - Security Considerations
> 
>     RATS Evidence, Verifiable Assertions and Results SHOULD use formats
>     ...
> 
>    Should that be
> 
>     RATS Evidence, Endorsements, Known-Good-Values, and Attestation
>     Results SHOULD use formats ...
> 
>    to be consistent with terminology? The term 'Verifiable Assertions'
>    shows up here the for the first time...

Yes, that is an oversight. Your text is correct. Which is good, because 
that means the text at least it was consistent until here and enabled 
you to find that artifact :) Thx!

> 
>     [...]  Nonce Claims often piggy-
>     back other information and can convey attestation semantics that are
>     of essence to RATS, e.g. the last four bytes of a challenge nonce
>     could be replaced by the IPv4 address-value of the Attester in its
>     response.
> 
>    Despite wondering whether this is a good thing or a bad thing, I
>    wonder why this is in the security considerations of the
>    architecture document. The architecture does not define how Nonce
>    Claims look like, so why would it discuss specific issues about
>    Nonce Claims?
> 
> [Hannes] I completely agree with you.

Good point, we will move it to the Interaction Model I-D (which is in 
churn right now, moving from one Model to potentially four models).

> 
> 
> Thanks again for the great review.

Dito! Vielen Dank!

Henk

> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>