RATS Agenda, Friday May 2d - Session I (1 of 1 meetings)

Online - meetecho

7:00 - 8:30 PDT (14:00 - 15:30 UTC)

Scribes: Hannes, Thomas, Usama

7:00 - 7:05 Agenda Bash & Logistics

(5 min) Kathleen Moriarty, Ned Smith

Henk: Multi-Verifier might take a bit longer than 15 minutes. It is OK
to give it an extra 5 mins?

Ned: Sure.

Usama: I put the questions into my slides. This will impact the length
of the presentation.

Ned: That is fine.

7:05 - 7:20 Multi-Verifier

https://datatracker.ietf.org/doc/draft-deshpande-rats-multi-verifier/
(15 min) Jun Zhang & Yogesh Deshpande

Yogesh presenting instead of Jun (who's having troubles with audio)

Attesters can be complex (multi-RoT, multi-components -- Example: CPU +
GPU), a single verifier may not be enough to carry out verification of
the complete systems.
Multiple verifiers need to come together and coordinate to finalise the
verification.

Possible arrangement

• hierarchical: a "lead" verifier is the front-end and dispatches to
  back-end verifiers the verification of individual evidence
  components. it then aggregates the attestation results (AR) into a
  single AR for the requester.

Hannes: (?)
Henk: to Hannes's question, the hierarchical approach allows
simplification.
Ned: not clear if partitioning of the Verifier is to specialise
different appraisal phases or for redundancy?
Yogesh: no the split is capability based and not for load balancing.
Vijay: (?)
Yogesh: depends on use case. The lead verifier has lots of smarts, not a
dumb dispatcher. E.g., if lead verifier must verify the overall
signature...

• cascaded: a chain of Verifiers that collaborate each verifying a
  some part of the overall Evidence and forwarding to the next in the
  chain until all Evidence is consumed.

These two arrangements can be combined.

Some use cases/existing implementations are presented:

• (existing implementation) Confidential Containers CCA Verifier
  (slide 6) based on cooperation between Trustee (lead) and Veraison
  (backend)

Usama: What is the privacy or security benefit of doing this?
Yogesh: the split is capability-based

Usama: Previously you said it is layered attester. Now you say it is
composite attester. I am very confused. So is this composite or layered
attester?

Henk: this is architectural work, not protocol work (therefore, it
shouldn't be standards track, it should be informational instead.)

Kathleen: I'll read the draft and provide comments

• (use case) Confidential training use case (using Intel TA and NVIDIA
  verifier)

Usama: question on the message flow and privacy. Good that NVidia
doesn't see the evidence that was intended for Intel. However, Intel
sees the evidence for NVIDIA. Can we design such that Intel does not see
the evidence for NVidia?
Yogesh: Intel TA is the lead, it cooperates with NVIDIA verifier

Hannes: Intel could access NVIDIA refvals / trust anchors and appraise
the combined evidence

• Thanassis: UDI reference framework. An example of privacy benefits
  from splitting the individual verifications across different
  verifiers

Yogesh: please read the draft and comment

7:20 - 7:25 Update on Evidence and Attestation Results Carrying protocol

(5 min) Michael Richardson

Will come back to MCR

7:25 - 7:40 CoSERV for Endorsement/RV Conveyance

(15 min) Paul Howard https://datatracker.ietf.org/doc/draft-howard-rats-coserv/

Paul H sets the scene: why (ecosystem fragmentation), what (a common
data format), how (reusing RATS type system as much as possible).
Thomas F presents the data format and prototype work in Veraison

7:40 - 7:55 Identity Crisis in Attested TLS for Confidential Computing

(15 min) Muhammad Usama Sardar - draft-fossati-tls-attestation https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/ https://datatracker.ietf.org/doc/draft-fossati-tls-exported-attestation/

Problem: if the verifier is not checking the instance identity of the
compromised TEE, a malicious CSP can confuse the relying party /
verifier by re-routing/diverting the attestation protocol to the
compromised TEE.

Solution: combine authentication and attestation.

Deb: ephemeral key in the certificate verify?
Usama: there are 2 keys: one is long-term (x.509) and one ephemeral
(evidence)
Deb: Which of these keys have certs associated with them?
Usama: both
Deb: who creates the certificate for the ephemeral key?
Usama: the HW root of trust of that device is
Deb: Who assesses/creates the certificate for the ephemeral key?
Deb: ephemeral is self-asserted then? This is not what is normally
expected in the TLS handshake (certificate/certificate verify)
Deb: you are mixing terminology from TLS and confidential computing.
Reusing TLS terminology with different semantics is confusing.
Hannes: RPKs use certificate verify without x509. This ship is already
sailed.

For slide 10/23, Thomas mentioned hybrid scheme where one can do
intra-handshake attestation first and then post-handshake attestation.

Usama: Still requires post-handshake attestation to be standardized

How to provision ID and LTK?

7:55 - 8:30 Open Mic

(35 min)

Thomas F: what is the conclusion of the discussion on adoption of
discovery using MUD?
Ned: There was an offline request to move it to a different WG.

Action for chairs: Lots of technical discussion in the chat. Plan
another interim meeting.