Re: [Rats] WGLC and IPR updates for RATs Architecture draft

[Thomas Fossati <[e-mail]>]

Hi Nancy, all,

On Mon, Oct 26, 2020 at 8:55 PM Nancy Cam-Winget (ncamwing)
<ncamwing=[e-mail]> wrote:
> This email is the start of a 3 week Working Group Last Call for the RATs architecture draft:
>
> https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/
>
> The WGLC will run until Nov 16, 2020.

This is our WGLC review of draft-ietf-rats-architecture-07.


** Summary:

The document is in fairly good shape and nearly ready to be shipped.

A big thank you to all the people involved!

** A few top-level points:

1) The split between Endorsements and Reference Values is not completely
   ironed out yet.  Endorsements are not super clearly defined.

This seems to be the only non-trivial missing piece.

2) The appendix on Handles needs some work to better clarify the concepts
   and simplify the flow.

3) It'd be great to do something around Terminology and use cases.  Simon
   has proposed rationale for restructuring as well as text to address
   the identified issues in PR#164 [1].  We'd be happy to help working on
   that until it can be merged.

[1] https://github.com/ietf-rats-wg/architecture/pull/164

4) The prose is at times a bit prolix and could be streamlined,
   especially in places where style tends to obscure the information
   content.

** Detailed comments and editorial suggestions:

[ Abstract ]

Maybe define the term "attestation" before using it in the phrase "such
remote attestation procedures"

[ 1.  Introduction ]

OLD
    This documents defines

NEW
    This document defines


OLD
   to enable implementers in order to choose appropriate solutions to
   compose

NEW
   to enable implementers to choose appropriate solutions to compose


OLD
   Appraisal Policy for Attestation Results:  A set of rules that direct
      how a Relying Party uses the Attestation Results regarding an
      Attester generated by the Verifiers.

NEW(a)
   Appraisal Policy for Attestation Results: A set of rules that directs
      how a Relying Party uses the Attestation Results generated by a
      Verifier.

or, if the Attester has to be mentioned:

NEW(b)
   Appraisal Policy for Attestation Results: A set of rules that directs
      how a Relying Party uses the Attestation Results generated by a
      Verifier in response to appraisal of Evidence from an Attester.

OLD
      [...]
      integrity of an Attester's various capabilities such as Claims
      collections and Evidence signing

NEW
      [...]
      integrity of an Attester's ability to collect Claims and sign
      Evidence.

OLD
   Relying Party:  A role performed by an entity that depends on the
      validity of information about an Attester, for purposes of
      reliably applying application specific actions.

NEW
   Relying Party:  A role performed by an entity that depends on the
      trustworthiness of information about an Attester, for purposes of
      taking application specific decisions.

[ 3.1.  Network Endpoint Assessment ]

OLD
   [...] version of information of the hardware and software

NEW
   [...] version information about the hardware and software


In the sentence "[...] record maintenance and/or trending reports
(logging)", it's not clear what "trending reports" have to do with
"logging"?


The para:

   Typically, solutions start with a specific component (called a "root
   of trust") that provides device identity and protected storage for
   measurements.  The system components perform a series of measurements

is probably not a very accurate description of what happens with
measured boot, i.e., that the measurer itself has to be part of the RoT.
It can't be a generic component whose measurements are (blindly?) signed
by the RoT.


OLD
   the hardware, firmware, BIOS, software, etc. that is running.

NEW
   the hardware, firmware, BIOS, software, etc. that is present.

(Using "present" because hardware is not strictly "running".)


OLD
   Relying Party:  A network infrastructure device such as a router,
      switch, or access point

NEW
   Relying Party:  A network infrastructure device such as a router,
      switch, or access point, responsible for admission of the device
      into the network.


[ 3.2.  Confidential Machine Learning (ML) Model Protection ]

OLD
   This typically works by having some protected environment in the
   device go through a remote attestation with some manufacturer service
   that can assess its trustworthiness.

NEW
   This typically works by having the ML application request attestation
   evidence from the device and engage with the manufacturer to assess
   the trustworthiness of said evidence.


[ 3.3.  Confidential Data Retrieval ]

The para:

   An assessment of system state is made against a set of policies to
   evaluate the state of a system using attestations for the system
   requesting data.

is not exactly crystal clear.  What about:

   As part of attestation procedure, an assessment is made against a set
   of policies to evaluate the state of the system which is requesting
   the confidential data.


[ 3.4.  Critical Infrastructure Control ]

This section could be expanded to include the case where the roles are
swapped: the sensor that provides critical input into a controller needs
to provide evidence of its trustworthiness before the controller can
comfortably act upon its stimulus (e.g., opening a valve.)


[ 3.5.  Trusted Execution Environment (TEE) Provisioning ]

Maybe an information reference to TEEP could be added here?


[ 3.6.  Hardware Watchdog ]

There seems to be some confusion here: initially it is said that the
"Relying Party is the watchdog timer in the TPM."  Subsequently, the
Relying Party is defined as "A remote server that will securely grant
the Attester [...]".  So, what is it?


[ 3.7.  FIDO Biometric Authentication ]

The definition of Relying Party:

   Any web site, mobile application back end or service that does
   biometric authentication.

seems slightly inaccurate: the web site doesn't do biometric auth.  The
authenticator binds biometric to crypto material so that the web site
can deal with usual crypto auth.


[ 4.  Architectural Overview ]

In Figure 1 there should be a mention to the Reference Value Provider.

OLD
   pppraisal policy to make application-specific decisions such as

NEW
   appraisal policy to make application-specific decisions such as


[ 4.2.  Reference Values ]

This seems to skip the relationship with the Reference Value Provider
now that's been split from the Endorser role, and also seems to muddle
the distinction between Ref-Values and Endorsements (i.e., Ref-Values
could be a subset of the information carried in an Endorsement.)


[ 4.3.  Two Types of Environments of an Attester ]

OLD
   Other examples may exist, and the examples discussed could even be
   combined into even more complex implementations.

NEW
   Other examples may exist.  Besides, the examples discussed could be
   combined into even more complex implementations.


OLD
   [...] taking measurements on code
   or memory and so on of the Target Environment.

NEW
   [...] taking measurements on code,
   memory or other security related objects of the Target Environment


"An execution environment [...]" is introduced without a definition.  It
might be not self-evident.  Is this an alias for TEE?  Or something
else?


The content of this para:

   By definition, the Attester role creates Evidence.  An Attester may
   consist of one or more nested or staged environments, adding
   complexity to the architectural structure.  The unifying component is
   the root of trust and the nested, staged, or chained attestation
   Evidence produced.  The nested or chained structure includes Claims,
   collected by the Attester to aid in the assurance or believability of
   the attestation Evidence.

is a slightly confusing.  What do we really want to say?  Also,
"nested", "staged", "chained": let's pick one and stick with it ;-)


OLD
   Figure 3 depicts an example of a device that includes (A) a BIOS
   stored in read-only memory in this example, (B) an updatable [...]

NEW
   The device in Figure 3 includes (A) a BIOS stored in read-only
   memory, (B) an updatable [...]


OLD
   Therefore, these Claims have to be measured securely.

NEW
   Therefore, the relevant Claims have to be measured securely.


This para:

   In general, the
   number of layers may vary by device or implementation, and an
   Attesting Environment might even have multiple Target Environments

introduces the capitalised "Attesting Environment" and "Target
Environment".  Do they deserve their own entry in the Terminology
section?


[ 4.5.  Composite Device ]

WRT the trust model of a composite device: it looks like the lead
attester needs to be trusted to collect the most fresh evidence from the
other slots?  Is this discussed anywhere?


In this para:

   After collecting the Evidence of other Attesters,
   this inside Verifier uses Endorsements and appraisal policies

Shouldn't Endorsements be Ref-Values instead?


[ 5.  Topological Models ]

The three sentences "There are multiple [...]", "This section includes
[...]" and "This is not intended [...]" are slightly vague.  It doesn't
seem to me that their information content is enough to justify them
being independent sentences.  Maybe they should be combined?


[ 5.1.  Passport Model ]

Should this section have a forward ref to the freshness section, or
otherwise discuss the freshness of the attestation results?


This para:

   There are three ways in which the process may fail.  First, the
   Verifier may refuse to issue the Attestation Result due to some error
   in processing, or some missing input to the Verifier.  The second way
   in which the process may fail is when the Attestation Result is
   examined by the Relying Party, and based upon the appraisal policy,
   the result does not pass the policy.  The third way is when the
   Verifier is unreachable.

not sure why is this relevant?


[ 5.2.  Background-Check Model ]

The para:

   Hence, the ability to let the Relying Party obtain an Attestation
   Result [...]

seems to reshuffle the content of the preceding one.  The two can be
combined / streamlined.


[ 5.3.  Combinations ]

   It is also worth pointing out that the choice of model is generally
   up to the Relying Party

I'm not sure it "is up to the RP", rather it "depends on the RP" because
it's typically not a choice of the RP but of the use case / protocol
flow in which the RP operates.


[ 6.  Roles and Entities ]

This sentence:

   An entity in the RATS architecture includes at least one of the roles
   defined in this document.

creates a bit of cognitive dissonance: in the Terminology section the
Endorser, Ref-val Provider, RP Owner and Verifier Owner are defined as
"entities", however, they don't include any of the roles (Verifier, RP,
Attester).


In the sentence:

   Alternative channels to convey conceptual messages [...]

maybe insert a forward reference to Section 8 (conceptual messages).


OLD
   As a system bus entity, [...]

NEW
   As a system bus-connected entity, [...]


[ 7.1.  Relying Party ]

OLD
   The scope of this document is scenarios for which a Relying Party
   [...]

NEW
   This document covers scenarios for which a Relying Party [...]



[ 7.2.  Attester ]

OLD
   The Verifier might share this information
   with other authorized parties, according to rules that it controls.

NEW
   The Verifier might share this information
   with other authorized parties, according to some predefined rules.


OLD
   In some cases where Evidence contains sensitive information, an
   Attester might even require that a Verifier first go through a TLS
   authentication or a remote attestation procedure with it before the
   Attester will send the sensitive Evidence.

NEW
   When Evidence contains sensitive information, an Attester typically requires
   that a Verifier authenticates itself (e.g., at TLS session
   establishment), and might even require a remote attestation before
   the Attester sends the sensitive Evidence.


[ 7.4.  Verifier ]

OLD
   is critical to the secure operation an Attestation system,

NEW
   is critical to the secure operation of an Attestation system,



[ 8.2.  Endorsements ]

This section doesn't provide a clear and concise definition of what is
meant by Endorsement.  Instead it goes in depth discussing the rather
tangent topic of access authorisation based on one kind of Endorsement.

I suggest this section is re-shaped to discuss:
* What is an endorsement conceptually;
  * Why we need to make it a first class object distinct from ref-values
    and other inputs to the verifier;
* A few instances of Endorsements;
* One example usage in the attestation workflow


[ 8.3.  Attestation Results ]

OLD
   Attestation Results
   may be a Boolean simply indicating compliance or non-compliance with
   a Verifier's appraisal policy, or a rich set of Claims about the
   Attester

NEW
   Attestation Results
   may carry a boolean value indicating compliance or non-compliance with
   a Verifier's appraisal policy, or a richer set of Claims about the
   Attester


This para:

   In some cases, it may
   even indicate that the Evidence itself cannot be authenticated as
   being correct

What does "authenticated as being correct" mean?
I suggest dropping the paragraph altogether.


OLD
   The simplest such policy might be to
   simply authorize any party supplying a compliant Attestation Result

NEW
   The simplest such policy might be to
   authorize any party supplying a compliant Attestation Result


But taking a step back, the whole para:

   The simplest such policy might be to
   simply authorize any party supplying a compliant Attestation Result
   signed by a trusted Verifier.  A more complex policy might also
   entail comparing information provided in the result against Reference
   Values, or applying more complex logic on such information.

does not seem to provide useful information, so maybe another option is
to drop it altogether.


OLD
   Thus, Attestation Results often need to include detailed information

NEW
   Thus, Attestation Results may need to include detailed information


In the sentence:

   Finally, whereas Evidence is signed by the device (or indirectly by a
   manufacturer, if Endorsements are used), [...]

I'm not sure what "or indirectly by a manufacturer, if Endorsements are
used" means?  Is it that Endorsement has the very tight meaning of
the "certificate of the device signing key signed by the manufacturer"?
If so, can we make this explicit in the Endorsements section?


[ 9.  Claims Encoding Formats ]

This sentence:

   To enable remote attestation to be added to existing protocols,
   enabling a higher level of assurance against malware for example, it
   is important that information needed for appraising the Attester be
   usable with existing protocols that have constraints around what
   formats they can transport.

it's quite hard to digest.

But more generally, the motivating use case (OPC UA) is slightly
convoluted, and I'm wondering whether it is really needed?  But
assuming it were, the exposition needs to be improved to present
a clear and compelling case.


[ 12.1.1.  On-Device Attester and Key Protection ]

OLD
   [...] a dedicated chip a TEE or such that [...]

NEW
   [...] a dedicated chip, a TEE or such that [...]


[ 12.2.  Integrity Protection ]

OLD
   Any solution that conveys information used for security purposes,
   whether such information is in the form of Evidence, Attestation
   Results, Endorsements, or appraisal policy must support end-to-end
   integrity protection and replay attack prevention,

NEW
   Any solution that conveys information used for security purposes,
   whether such information is in the form of Evidence, Attestation
   Results, Endorsements, Reference Values or appraisal policy, must
   support end-to-end integrity protection and replay attack prevention,


[ 16.3.  Example 3: Handle-based Passport Model Example ]

I have a bunch of nits on this but I think the whole section lacks
clarity and conciseness.  I'd be happy to help with a makeover.


cheers!