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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Oct 2019 09:00:32 +0000

Hi Jürgen,

Thanks for your review. Looks of great questions.
Below is my take on it.

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Schönwälder, Jürgen
Sent: Mittwoch, 25. September 2019 16:18
To: [email-masked]
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:

"

- 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

- What are 'architectural constituents'?

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

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

- Not sure this helps me understand things:

  (e.g.  Prinicipals that are Supply Chain Entities)

- What are Appraisals?

   [...]  Attestation Results are the output of appraisals.

  There is text in 3.3 about appraisals that I do not understand.  If
  Attestation Results are the output of appraisals, then appraisals
  are some form of a function. I thought that the Verifier is creating
  appraisals based on the received Evidence and the received
  Endorsements and that leads to Attestation Results, i.e., in a
  functional writing style:

  Verifier :: Known-Good-Values -> Endorsements -> Evidence -> Attestation Results

  This is also how I understand the definition of Verifier in 4.3.1.
  It seems appraisals are something internal to the logic of the
  Verifier, i.e., they may be produced by the logic of the Verifier but
  then the Attestation Results are really the output of the Verifier.

- Evidence

  I understand that Evidence is a specific form of a claim. I am not
  sure, though, what exactly turns a claim into Evidence.

   o  Evidence is provable Claims about a specific Computing Environment
      made by an Attester.

  What makes a claim a provable claim? Who is originating the claim
  and who is originating the Evidence?

- Endorsements

  It is not clear to me yet what the difference between Endorsements
  and KGV really is.

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

   [...]  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?

- Editorial

  s/capabile/capable/

  Singular/plural confusion in the following?

   Likely, there are a set of Claims that is widely applicable across
   most, if not all environments.  Conversely, there are Claims that are

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats
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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Oct 2019 09:11:19 +0000

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 <[email-masked]>; [email-masked]
Subject: RE: comments on draft-birkholz-rats-architecture-02

Hi Jürgen,

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Schönwälder, Jürgen
Sent: Mittwoch, 25. September 2019 16:18
To: [email-masked]
Subject: [Rats] comments on draft-birkholz-rats-architecture-02

Hi,

I guess we have to change the sentence altogether from "

"
This document defines terminology and describes the architecture of the remote attestation procedures (RATS) standardization work in the IETF.
"

  - Claims
  - Evidence
  - Known-Good-Values
  - Endorsements
  - Attestation Results

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

[Hannes] Should be replaced with 'entities'

- Separation:

[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.

[Hannes] I have to agree with you. Maybe it helps to move Figure 1 up or to re-arrange other sections.

[Hannes] Maybe a complete example would help.

- What are Appraisals?
~snip~
- Evidence
~snip~
- Endorsements
~snip~

[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).

  Should that be

[Hannes] I completely agree with you.

Thanks again for the great review.

Ciao
Hannes

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 2 Oct 2019 11:59:34 +0200

Hi Jürgen,
hi Hannes,

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

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

> [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?

> [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.

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

> [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?

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

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

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

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