RATS Session Meeting Minutes

Summary

The RATS working group session covered updates on several drafts, administrative items, and discussions on the path forward for new and existing work. Key technical updates included the integration of CWT claims into CoRIM for better interoperability and revised definitions in the PKCS Evidence for HSM attestation draft. The group also discussed a taxonomy for composite attesters and a hackathon implementation of TIP with Bayesian. A significant portion of the session focused on administrative guidance from the chairs and AD, emphasizing the need for more working group reviews to clear the existing document backlog before adopting new work. A proposal for a security considerations guideline document sparked a lengthy discussion regarding its scope and format, with a consensus leaning towards a template or wiki-based guidance rather than a full threat model published as an RFC.

Key Discussion Points

Administrative & Document Progress:
- Chairs requested more working group reviews and volunteers for document shepherding to clear the current backlog of drafts. This is crucial for progressing existing documents and opening capacity for new work.
- Michael Richardson volunteered to shepherd the "Device Subscription ID" draft.
Concise Reference Integrity Manifest (CoRIM):
- The draft has closed 13 issues and 20 pull requests since the last IETF, with its feature set now frozen.
- Technical Update: CWT claims were added to the COSE header for enhanced interoperability with existing IETF standards (specifically RFC 9597), allowing validity to be expressed using standard CWT claims. The current CDDL supports both legacy and CWT claims, with CWT being the preferred method.
- Technical Update: A diagram illustrating the CoRIM Verifier processing flow was added to the document.
- The AD confirmed that early security and ART directorate reviews for CoRIM can be requested immediately.
- Discussion on the IESG review process clarified that working group reviews should precede IESG reviews, as early directorate reviews do not guarantee AD attention or prevent later "discuss" comments.
- Concerns were raised about the urgency of CoRIM reaching a stable stage due to active implementations and industry dependencies.
PKCS Evidence for Remote Attestation of Hardware Security Modules (HSM):
- The "root of trust" concept was removed, and attribute definitions were aligned with EAT and PKCS11 specifications.
- Technical Contribution: The "Role of Presenter" was introduced to define an entity that initiates attestation for HSMs (which cannot attest themselves) and selects what evidence is disclosed, without holding cryptographic state.
- Technical Contribution: The concept of "entities" (e.g., keys, platforms) and "attributes" (claims) was introduced to handle the large addressable state of an HSM, allowing selective disclosure of evidence.
- Feedback was requested on changing "entity" to "subject" and whether the "Role of Presenter" should be a more general RATS specification.
- Discussion clarified that HSMs only attest to what they directly observe and cannot attest to external correctness. There was a debate about whether a "Presenter" can truly create evidence given RFC 9334's definition of an "Attester."
Remote Attestation with Multiple Verifiers:
- The draft clarified its scope, including motivation, use cases, architecture, security, and privacy, while temporarily excluding verifier discovery/selection and inter-verifier message formats.
- Technical Update: New use cases for multi-component attestation (e.g., CPU+GPU from different vendors) and confidential computing workload verification were added.
- Security & Privacy: The draft outlines threat models for hierarchical, cascade, and hybrid multi-verifier patterns, emphasizing mutual attestation and encryption to mitigate sensitive information leakage. Evidence between the attester and relying party is out of scope.
- Discussion highlighted industry concerns regarding vendor unwillingness to release policies, which drives the need for multiple verifiers.
Integration of Remote Attestation with Key Negotiation and Distribution:
- Introduced a new use case for large language model deployment in private networks.
- Technical Update: Key binding mechanisms were added to prevent "derivation attacks" (key delivery to unintended users) by binding attestation messages with an attested ID (public key/certificate).
- The goal is a lightweight key management solution integrated with remote attestation, usable with attested TLS and other protocols.
- Two main modes (passport and background check) and three use cases (public cloud, secure channels for sensitive data, private network LLM deployment) were presented.
Taxonomy for Composite Attesters:
- Seven classes of composite attesters were presented with diagrams to provide a common language for discussion within the working group.
- Classes range from simple, non-composite attesters to complex scenarios involving local verifiers, external component verifiers (background check and passport models), chained attestation, and recursive composition.
- Discussion focused on potential redundancies between classes (e.g., Class 1 vs. 3B, Class 2 vs. 3P) and the completeness of the taxonomy, acknowledging that very complex scenarios (like mobile phones) might not fully fit.
- A suggestion was made to redefine the taxonomy based on fundamental components (e.g., what each attestation environment claims) rather than distinct patterns, which could better categorize the infinite combinations.
Hackathon: Secure Software Provisioning with TIP and Variation:
- A hackathon project demonstrated the viability of the TIP protocol for remote attestation using Bayesian as a verifier, to securely provision WASM applications.
- Technical Feedback: Issues were identified with existing Bayesian plugins and the EAT attestation result module regarding support for CBOR encoding and specific claims required by the TIP EAT profile. A generic EAT plugin for TIP was implemented.
Guidelines for Security Considerations in RATS:
- A new draft was proposed to provide a baseline for threat models and security/privacy considerations for RATS documents, aiming for consistency and ease of reference.
- The proposal included an outline covering system models, actors, legal requirements, threat models (adversary powers, security goals), typical attacks, and potential mitigations.
- Discussion: The AD and other participants expressed strong reservations about publishing a full "threat model" as an RFC, citing the effort involved, the rapid evolution of threats, and the potential for it to become a "never-ending document."
- There was a general consensus that a template or guidance for security/privacy considerations (perhaps as a non-RFC document or wiki entry) would be highly valuable for authors to ensure consistency and quality across drafts, but it should focus on guiding questions and structure rather than an exhaustive threat model.
- It was suggested that if specific security issues are identified in existing RFCs (e.g., misinterpretation of CTI claims), these should be addressed via update documents.

Decisions and Action Items

Chairs: Will request early security and ART directorate reviews for the CoRIM draft.
Working Group Participants:
- ACTION: Review existing documents to help clear the backlog. The chairs will provide a list of urgent documents.
- ACTION: Volunteers are encouraged to step forward for document shepherding.
- ACTION (CoRIM Authors): Address any outstanding review comments, especially the new issues filed by Usama and the shepherd review comments.
- ACTION (PKCS Evidence for HSM Authors): Continue bi-weekly meetings. Seek feedback on nomenclature ("entity" to "subject") and the placement of the "Role of Presenter" definition.
- ACTION (Multiple Verifiers Authors): Continue work on security and privacy considerations, with a goal of having a robust section before a call for adoption.
- ACTION (Key Negotiation & Distribution Authors): Engage with Thomas on the RatsDI API for attestation request messages. Further improve security and privacy considerations.
- ACTION (Hackathon Presenters): Kenta Takayama confirmed he will contribute pull requests based on the identified issues with Bayesian and EAT profile support for TIP.
- ACTION (Usama - Security Guidelines): Collaborate offline with chairs and AD to refine the scope and format of the security considerations guidance, likely moving towards a template or wiki-based approach rather than an RFC for a full threat model.
Michael Richardson: Will update the "Conceptual Message Wrapper" draft (v19/20) and send it to the AD. He will also ping Peter Lee for any outstanding review comments.

Next Steps

The working group will prioritize reviewing and progressing existing documents to clear the backlog.
The chairs will revisit adoption calls for the "Remote Attestation with Multiple Verifiers" and "Integration of Remote Attestation with Key Negotiation and Distribution" drafts once the backlog is sufficiently cleared and security/privacy considerations are robust.
Discussions on the "Taxonomy for Composite Attesters" will continue, potentially exploring a more granular, component-based approach to defining classes.
The conceptual "Guidelines for Security Considerations in RATS" work will proceed with an adjusted scope, focusing on creating a reusable template or wiki-based guidance for security and privacy considerations for future drafts.
The "Reference Interaction Model" draft needs to address outstanding shepherd review comments.
The "Conceptual Message Wrapper" draft is expected to be published as a new version and moved to telechat after final AD review.

Session Date/Time: 07 Nov 2025 16:30

RATS

Summary

The RATS session covered updates on the Co-Serve draft (now a Working Group adopted document), a new proposal for Trustworthy Workload Identity in RATS aiming for "relying party empathy" and business-centric claims, a discussion on standardizing Geographic Claims for attestation results, and a detailed presentation on Threat Modeling for RATS, highlighting issues with replay, relay, and diversion attacks, and proposing improvements to existing RFCs. The session emphasized the need for more focused technical discussions and clearer definitions of security considerations for researchers and protocol designers.

Key Discussion Points

Co-Serve (Concise Selector for Attestation Endorsements and Reference Values)
- Progress Update: Paul announced that draft-ietf-rats-co-serve is now an adopted Working Group document. Two new co-authors, Gary and Ding, have joined.
- API Bindings: Version 2 of the draft includes concrete HTTP API bindings, specifically a transactional request/response model using HTTP GET where the query is part of the URL path. This enables deterministic CBOR encoding of queries and leverages HTTP caching.
- Service Discovery: A service discovery protocol using RFC 8615 well-known URLs has been added. The discovery document provides API endpoints and supported media types, conveyed in CBOR or JSON.
- Future Work: The focus will shift to shoring up existing content, specifically enhancing the supply chain threat/trust model, and improving security and privacy considerations (particularly regarding the aggregation concept). All feedback is being captured in GitHub issues.
- Running Code: A proof-of-concept (POC) implementation for server-side Co-Serve is now mainline in the Verrazon project. This allows Verrazon to act as an endorsement district and reference value provider. Experimental proxy plugins demonstrate Co-Serve as a proxy layer to external cloud services (Nvidia Rim, KDS). Golang and Rust common library support for the Co-Serve data model is in progress, building towards an end-to-end client-side story.
- Discussion: Usama queried the role of an "aggregator" in the Co-Serve model, particularly in the context of the running code examples. Paul clarified that aggregation is an implementation detail, not a prescriptive architectural requirement, but the data model must be rich enough to support it if implementers choose to use it. Thomas (via chat) affirmed that the aggregator should not be dropped from the draft to analyze its implications.
Trustworthy Workload Identity in RATS
- Motivation: Mark Nova presented a joint submission from the Trustworthy World Identity Special Interest Group at the Confidential Computing Consortium. The goal is to expand the total addressable market for confidential computing by making workload identity manageable and deployable at scale. He highlighted that current RATS attestation results are "fragile" (e.g., based on firmware versions, boot counts) and not "relying party friendly," leading to unmanageable deployments.
- Claims Mapper: A new architectural building block, the "Claims Mapper," is proposed. It takes evidence or attestation results as input and outputs a stable, business-centric workload identity and additional claims (e.g., "running on approved hardware," "located in Germany").
- Credential Acquisition Mechanisms: The proposal outlines various flows for obtaining a credential key (self-generated or retrieved from a key store) and a credential (from verifier, credential authority, or workload owner), contingent on remote attestation. Four specific flows were presented, involving interactions between workload, verifier, credential authority, and key store.
- Security Considerations: Identified key trusted entities (verifier, CA, key store) and the need for TLS between them. Challenges include maintaining claims during live migration (e.g., from Germany to France) and protecting against relay, replay, and redirect attacks.
- Discussion: Aaron raised concerns about compatibility with the Wimsy architecture (e.g., agent-based attestation, lack of crypto binding for transaction tokens). Mark acknowledged architectural incompatibilities but stressed the need for solutions compatible with existing enterprise identity systems. Gary questioned the need for a separate workload identity when platform-specific attestation (like AMD SEV S&P) already provides attested workload identity. He also expressed concern about third-party credential issuance based on a one-time attestation, where the security state might change later (e.g., during live migration). Mark emphasized hardware-neutral, business-centric policies for broad adoption. Hank noted that the Claims Mapper functions like an appraiser procedure and could potentially be integrated into a verifier.
Geographic Claims for RATS
- Problem Statement: Michael Richardson presented the challenge of consolidating diverse geographic attestation methods into a single, consistent result for relying parties. The goal is for a verifier to produce a single geographic result (e.g., jurisdiction) without the relying party needing to understand the underlying method.
- Methods: Discussed methods include auditor endorsement, GPS, LTE tower triangulation, and speed-of-light measurements.
- Document Organization: Michael sought input on how to structure the work: a single document with appendices for methods, or multiple method-specific documents feeding into a common results document.
- Use Cases: Highlighted regulatory compliance (e.g., GDPR requiring location in EU), AI agent interactions, and contractual obligations.
- Discussion: Usama sought clarification on how a verifier would judge location, noting the importance of jurisdiction over precise coordinates. Michael explained that mechanisms could include signed endorsements, trusted data from cellular providers, or physics-based proximity measurements, all abstracted by the verifier to a simple jurisdiction claim. Mark suggested this is a special case of composite attestation and should align with how other hardware claims are handled. Diego recommended separating the evidence building/exchange (core RATS) from specific location methods (referenced externally). Hank proposed including freshness (timestamp, epoch ID), source of claim processing, an IANA registry for location methods, and considerations for distributed systems in the attestation results. Deb raised concerns about privacy implications of location data.
Threat Modeling for RATS
- Focus: Usama Dresden provided a technical deep dive into threat modeling, focusing on replay, relay, and diversion attacks, and proposing concrete mitigations. He emphasized the need for RATS documents to clearly articulate security and privacy considerations for researchers and protocol designers.
- Replay Attack: Described replay scenarios across multiple connections (where attester state changes) and within a single connection.
  - Mitigation: Freshness criteria (nonces, synchronized timestamps, epoch IDs/handles). Usama noted confusion around existing definitions of "epoch handle" and "epoch ID" in RFCs.
- Relay Attack: Explained how an adversary can forward a nonce to a genuine attester, obtain valid evidence, and then impersonate the genuine attester to the relying party.
  - Mitigation: Binding the evidence to the specific secure connection/channel (e.g., TLS).
- Diversion Attack (For-Shadow Attack): A network adversary redirects a connection intended for a specific infrastructure provider to a compromised machine.
  - Mitigation: Binding the evidence to the infrastructure provider (e.g., proving the attester is in a Meta data center).
- Proposed Specification Improvements:
  - Unprotected Evidence (RFC 9334): Usama argued that unsigned evidence is "completely useless" and offers no security advantage over basic TLS, emphasizing the need for a signature chain to a root of trust.
  - Missing Roles/Messages (RFC 9334): Highlighted the absence of an "identity supplier" role and a conceptual "identity" message, which are crucial for distinguishing genuine attester replicas and preventing consensus manipulation. Also, identified a missing "Attestation Challenge" message for freshness.
- Discussion: Hank agreed with most mitigation methods, especially channel binding for replay attacks. He also noted that if an attester produces "unbelievable" (false) evidence, it implies a broken TCB/root of trust. Usama clarified that replay involves replaying old, valid evidence, not generating false evidence. Deb suggested filing individual issues on GitHub for each problem raised to facilitate consensus, but Usama questioned where to file issues for existing RFCs. Jean noted that RFC 9334's appendix already addresses replay through the concept of "thresholds" for acceptable staleness.

Decisions and Action Items

Co-Serve Draft (draft-ietf-rats-co-serve): Continue development based on GitHub issues and working group feedback. Focus on strengthening the threat/trust model and security/privacy considerations.
Trustworthy Workload Identity: No immediate decisions, the proposal is for further working group discussion and potential adoption.
Geographic Claims: No decisions made; Michael Richardson is seeking input on the organizational structure of the associated documentation.
Threat Modeling for RATS:
- The chairs will establish a mechanism (e.g., GitHub issues, wiki for future drafts, or updates to RFCs) to track and address Usama's points regarding security considerations and specification improvements.
- Usama is encouraged to submit his comments and concerns to the RATS mailing list for further discussion.

Next Steps

Co-Serve: Co-authors to address outstanding GitHub issues, particularly around the supply chain threat model and security/privacy considerations. Continue proof-of-concept implementations to validate the specification.
Trustworthy Workload Identity: Authors to engage with the working group on the mailing list for detailed analysis of the proposed flows and security implications.
Geographic Claims: Further discussion on the mailing list to determine the preferred document organization and scope for standardizing geographic attestation results.
Threat Modeling for RATS: The chairs will work to facilitate the tracking and resolution of Usama's detailed security concerns and proposed improvements across relevant RATS documents.
General: Chairs noted the need for more interim meetings to allow for focused, in-depth technical discussions to achieve consensus on various topics. Working group participants are encouraged to provide reviews on drafts ready for progression to Last Call.