Online - meetecho
7:00 - 8:30 PDT (14:00 - 15:30 UTC)
Scribes: Hannes, Thomas, Usama
(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.
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
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...
These two arrangements can be combined.
Some use cases/existing implementations are presented:
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
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
Yogesh: please read the draft and comment
(5 min) Michael Richardson
Will come back to MCR
(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
(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?
(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.