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

[Kathleen Moriarty <[e-mail]>]

Thank you for your quick response!

Best regards,
Kathleen 

Sent from my mobile device

> On Jul 23, 2021, at 5:42 PM, Thomas Fossati <[e-mail]> wrote:
> 
> Hi Kathleen,
> 
>> On Fri, Jul 23, 2021 at 10:10 PM Kathleen Moriarty
>> <[e-mail]> wrote:
>> 
>> Thomas,
>> 
>> Thank you for your detailed review. I am reading the document again to make sure all comments were addressed, but also wanted to check with you that you were satisfied with how your comments were addressed.
> 
> Our comments have been discussed thoroughly with the editors in
> multiple DT meetings and addressed to our full satisfaction.
> 
> This is a very solid document.
> 
> cheers, t
> 
>> 
>> Best regards,
>> Kathleen
>> 
>>> On Wed, Nov 18, 2020 at 11:55 AM Thomas Fossati <[e-mail]> wrote:
>>> 
>>> 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!
>>> 
>>> _______________________________________________
>>> RATS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rats
>> 
>> 
>> 
>> --
>> 
>> Best regards,
>> Kathleen
> 
> 
> 
> -- 
> Thomas