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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Thank you for the feedback Thomas....
I believe Michael is pulling the architecture team (and design meetings) together to address your and Guy's comments.

Best, Nancy

On 11/18/20, 8: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!