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

[Kathleen Moriarty <[e-mail]>]

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.

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