flashbots / flashbots/attested-tls
Allow verification at an explicit timestamp, and report which collateral was used
- Dominant language
- Rust
- Stars
- 5
- Forks
- 3
- Avg merge
- 4d 1h
- Merged PRs (30d)
- 8
Description
Hello :) Dropping this Claude-authored issue. Think it's clear/clean enough as is, but happy to chat about it if it needs clarification.
### The problem: archived attestations stop being verifiable
We use the `attestation` crate as a relying party for a one-time event rather than a live
handshake. When a Seismic network is founded, each founding node produces Azure TDX +
vTPM evidence bound to its freshly generated keys; we verify it against a measurement
policy, and we archive the evidence as permanent provenance. Those founding keys enter the
genesis validator set, so "this key came from a real TEE running this image" is a claim
later readers need to check for themselves, years afterwards.
Today they can't. Re-verification goes through `AttestationVerifier::verify_attestation`,
which verifies at `SystemTime::now()` against collateral fetched now. TCB Info, QE Identity
and both CRLs carry `nextUpdate` on a roughly 30-day cadence, and the Azure AK chain has an
ordinary `notAfter`. So about a month after founding, re-verification of perfectly good
archived evidence starts failing, and the property degrades into "the operator says it
verified once".
What we want is the validity-at-creation-time property archived evidence is supposed to
have: evaluate the chains and TCB status as of when the evidence was collected, against the
collateral that was current then.
### The crate is already almost there
All the machinery exists — a single `now` already gates every freshness check (root CA CRL,
TCB Info window and chain, QE Identity window and chain, PCK chain validity, and the Azure
AK chain via `verify_ak_cert_with_azure_roots`), and `Option` already
means "use this, don't fetch". `verify_dcap_attestation_with_given_timestamp` and
`verify_dcap_attestation_with_timestamp_sync` are public and take both.
Your own tests rely on exactly this, for exactly our reason:
```rust
// crates/attestation/src/dcap.rs
// To avoid this test stopping working when the certificate is no longer
// valid we pass in a timestamp
let now = 1769509141;
```
The gap is only that the parameterization doesn't reach the two places we have to go
through:
1. **The Azure path.** `verify_azure_attestation_with_given_timestamp` and its `_sync`
sibling take `now` and `Option`, but are module-private; the two
public entry points bind `now` to `unix_time_now_secs()`.
2. **`AttestationVerifier`.** We need the measurement-policy check, so we can't call the
DCAP function directly — and `verify_attestation` has no way to pass either input.
And one thing genuinely missing: **nothing reports which collateral bundle a verification
used**, so there's no way to archive it.
### What we'd need
Two additions, no wire or payload change:
1. An optional `(collateral, now)` input pair on the `AttestationVerifier` verify call —
`Some(collateral)` meaning "no network fetch", `None` for `now` meaning "wall clock", so
existing behaviour is the default.
2. The collateral the verification actually used, in the verify result.
The second one matters more than it looks. The obvious workaround — fetch a second copy
alongside verification and archive that — is subtly wrong: a PCCS cache refresh between the
two fetches makes the archived bundle *a* bundle rather than *the* bundle the verification
consumed. For provenance that distinction is the whole point.
Nothing else is needed for our case. `QuoteCollateralV3` already derives serde, and every
other time-sensitive Azure input (AK leaf, AK intermediates, vTPM quote, HCL report, TD
quote) already rides in the evidence message, with the Microsoft/Azure roots compiled in.
DCAP collateral is the only input a verifier fetches, so these two changes close the gap
completely.
### How this relates to work in flight
- **#58 / #63 / #65** are about *where collateral comes from*, to avoid a fetch during a
handshake. This is about *which instant verification is evaluated at* and *what the
verifier reports* — orthogonal. If #65 ever lands, archived evidence would carry its
collateral for free, which suits us, but we'd still need the explicit `now`, since
bundling collateral doesn't stop it expiring.
- **#70 (verifier builder)** composes cleanly: `now` and `collateral` are per-verification
inputs, not per-verifier configuration, so they belong on the call rather than the
builder.
- **#79 (return `ExpectedMeasurements`)** touches the surface our second ask needs. Since
the return type is already changing there, a small outcome struct carrying both the
matched measurements and the collateral used would fold in naturally. I'd rather propose
against the direction you're taking than cut across it — hence this issue before a PR.
Nothing here adds to the evidence payload, so it's also neutral with respect to the rustls
64 kb cap in #75.
Happy to implement whichever shape you prefer, and to wait for #70/#79 if they're close.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with crates/attestation/src/dcap.rs and the timestamped DCAP verification tests, then trace verify_azure_attestation_with_given_timestamp and AttestationVerifier::verify_attestation. The change is complete when verification can accept optional collateral and an explicit timestamp while preserving wall-clock defaults, and its result reports the collateral actually used.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, rust
- Domain
- cryptography, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100