RATS Virtual Interim Agenda, Friday Sep 27th, 07:00 PDT
7:00 - 7:05 Agenda Bash & Logistics
(5 min) Nancy Cam-Winget, Kathleen Moriarty, Ned Smith

7:05 - 7:10 RATS: Evidence Carrying Protocols
(5 min) Michael Richardson - RFC9334

Michael was sick and did not present.

7:10 - 7:25 Attester Groups for Remote Attestation
(15 min) Jun Zhang - draft-labiod-rats-attester-groups-00

Jun presents the slides at
https://datatracker.ietf.org/doc/slides-interim-2024-rats-01-sessa-attester-groups-for-remote-attestation/

• The document puts forward an extension of the RATS architecture to
  allow "attester groups"
• Use cases from fleets of aircrafts and automotives
• Requires modifying the attester definitions (e.g., in composite
  there is no lead, the identification is per-group rather than
  per-instance.)

Kathleen: Attestation Sets (now Posture Assessment) exists already. We
need to sync the two efforts and decide how to proceed (e.g., merge?).
We need to hear what the WG thinks.

7:25 - 7:40 Handling multiple verifiers in RATS architecture
(15 min) Jun Zhang - draft-zhang-rats-multiverifiers-00

• Verifier is single point of failure in the architecture.
• We need to allow multiple verifiers for improve the resiliance
• However, there are problems (conflicting views, untrusted verifier
  in the pool)
• Extension of the BG-check model
• Introduce the "Verifier manager" which is a new role paired with the
  RP
• Use case 1: Node attestation for trusted routing
• Use case 2: Attestation in data centers
• Depending on policy, the RP might have to wait for all the AR to
  come resulting in additional latency.

Giridhar Mandyam (@chat): "Simplifying policy"? Wouldn't each verifier
still need a separate appraisal policy? One VM will be able to disperse
Appraisal policies to the verifiers pool. This does not simplify
appraisal policy.

Hannes Tschofenig (@chat): Is there an interoperability issue that needs
to be taken into account with this approach? It looks like an
implementation strategy to me.
Is there a single "logical" verifier which scales out for resiliency
reasons, or are these different verifiers from different administration
domains? If they are not synchronized (i.e., they are similarly
configured) then how do we reason about the results? (e.g., freshness)

Ghada ARFAOUI (@chat): is it the same evidence that is sent to all
verifiers? or the Relying party will transform the evidence depending on
the verifier ?

Jun: it could be, if verifiers are able to parse different evidence
formats and translate them to some common format.

Kathleen: routing and networking expertise is needed to understand the
implications on the network, attestation experts are not sufficient. A
diverse audience will be needed to take care of this document (i.e., not
only RATS.)

Zhang Jun: the document is not limited to network. (e.g., see use case #
2 on attestation in data centers)

Nancy: some of this feels to me like it's implementation specific rather
being architectural.

Ghada ARFAOUI (@chat): are verifier A, B and C instances of the same
verifier?
Jun: verifier A, B, C are different verifiers

Ghada ARFAOUI (@chat): So the verifiers A, B and C are going to verify
the property but using different ways? How do you aggregate the
attestation results ?

Carl Wallace (@chat): I don't really follow how a relying party is
supposed to adjudicate a misbehaving trusted (!) verifier.

• Ned (@chat): I think resillience is one of the use cases. But not if
  they produce different results

  • Carl Wallace (@chat): Sure. It's the different results and the
    allocation of responsibility for making sense of different
    results that loses me.

• Zhang Jun: The verifier manager will handle it as it is more
  knowledgeable. Such verifiers will not be recommended later.

  • Verifier manager makes more sense (though at that point the
    verifier manager is essentially a verifier)

Hannes (@chat): It would be good to talk about what level of
"compromise" of the verifier we are talking about.

Henk (@train): this is more about the conceptual message flow rather
than use case specific (network, as Kathleen mentioned). There is a need
for interop which is not guaranteed with what is in the RATS toolbox at
present, especially, if Relying Parties face the challenge of selecting
Verifiers based on the RP policy in background-check models. There is no
role responsible for "connecting RPs to appropriate groups of Verifiers"
in the current architectural layout. If interoperability of Verifiers in
scales from "well controlled by one authority" to "global available
standardized Verifiers" is a goal, there are basic architectural parts
(including maybe Verifier APIs) missing here.

Hannes (@chat): It would be good to write this up to better understand
the contribution.
I wonder whether it is a good idea to separate the concept over two
drafts given they seem to belong together.
It also appears that the Verifier Manager is actually a single point of
failure in the architecture.

• Zhang Jun (@chat): Verifier Manager is a translator in nature which
  can be implemented in a distributed way to prevent the single point
  of failure.

7:40 - 7:55 Towards Comprehensive Formal Specification of Attestation
Frameworks for Confidential Computing
(15 min) Muhammad Usama Sardar - draft-fossati-tls-attestation

Looking at verification of the whole architecture.
Focus on Confidential Computing. We need more than high-level RATS
architecture to reason about the security, specially the bootstrapping
phase.
Non necessarily open-source.
Example use case: SCONE
Eliciting feedback / comments from the RATS group.

7:55 - 8:00 Open Mic
(5 min) All

no topics.