Repository navigation
Alternative to RATLS #113
Description
Summary
There's discussion about moving away from relying solely on Remote Attestation TLS (RATLS) and considering alternative approaches for secure communication between services.
Current Approach
Currently using RATLS for several services:
- KMS: onboarding RPC, key providing RPC
- tproxy: registering RPC
- CVM: Inter-App Secure Communication (WIP)
Concerns
- Performance issues with RATLS (~1s for Azure to establish connection, longer if PCCS fetch needed)
- RATLS hides some implementation details which may be less transparent
Alternative Approaches
- Application-level attestation: Exchange regular TLS certificates along with their attestations
- Pre-registration approach: Have each KMS instance register locally generated TLS cert+attestation on boot
Considerations
- Remote attestation must happen at some level (TLS, HTTP, or Application)
- TLS-level attestation is easier to abstract and reuse across services
- Application-level attestation makes the security more visible but requires additional MITM protections
- Performance is critical for inter-app communication, less so for registration/onboarding
Activity
h4x3rotab commentedon Jun 30, 2026
Maintainer triage update: this remains open intentionally and is listed separately from vulnerability reports in the security roadmap/hardening table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#related-security-roadmap-and-hardening
Disposition: architecture roadmap. This tracks possible application-level attestation or pre-registration alternatives to RA-TLS.