Forking this thread to focus specifically on the goal of ensuring that the result is deployable (practical, manageable, robust, cost-effective, …)
Here are my main concerns. They are interrelated. 1. A preferable architectural approach is one that is built around separation of concerns. In this case, that would mean separating how the workload procures its credentials from how the credential is used. In this case, one key benefit is not changing TLS, which means that both endpoints of a secure channel do not need to implement the new protocol extensions to be able to establish a secure channel. 2. The replay threat, I believe, is no longer relevant if you separate procurement of credential from its use. I care about replay as much as the other guy, but TLS is designed to avoid replay, so long as you don’t make attestation part of the flow. Issued workload credentials could be given limited lifetimes to mitigate the risk of workload going stale and still appearing to meet policy. 3. A stable relying party authorization policy is absolutely essential to robust deployments. Any solution that requires, for example, a client upgrade to have the operator push a change to every relying party instance that client might communicate with, is a non-starter. A typical authorization policy might look like “instance of payroll application, located in Germany”. That kind of authorization policy will remain stable for years and not be affected by change in reference values corresponding to “payroll application”. 4. Introducing a service into a client-server communication tends not to work. This is why Intel had to implement DCAP for SGX — a cloud provider would never allow Intel’s attestation service to be a prerequisite for meeting its SLOs. If a Verifier must be always on, always available, universally reachable (so, not even intermittent network outages) and highly performant, the result is a new very expensive, likely dial-tone, service that an enterprise must now maintain. Highly a non-starter. 5. By making attestation part of TLS secure channel establishment, you are faced with violating either requirement 3 or requirement 4 above. Note that violating either requirement is a non-starter. 6. The current proposal does not explain how workload attestation (“payroll application”) is combined with platform attestation (“hosted in Greece”). I can’t critique how well it does that because it doesn’t explain how it does that. 7. If an organization wants to standardize on some workload identity standard, such as WIMSE or SPIFFE, the proposal does not specify how it can do that while also adopting the proposal. Forcing an enterprise to do things two different ways is a big adoption hurdle. 8. Most IT systems today are either horizontally scaled or serverless, and reverse proxies are ubiquitous. The proposal must explain how it handles these cases. Circling back, to my original point, if we separate credential procurement from credential use, we get better answers to all of the points just listed. On Tue, Jul 22, 2025 at 12:27 AM Muhammad Usama Sardar < [email protected]> wrote: > Thank you all for constructive discussion and valuable feedback. Since I > could not reach my last slide, I want to particularly thank all of the > people listed there for their valuable contributions to this work over the > years. > A quick follow-up with pointers: > > - *Pre-handshake attestation* protocols (including the widely used > Intel's RA-TLS) do not provide *per-session Evidence freshness*. This > is formally analyzed in [1], and was presented in detail at UFMRG in IETF > 120 [2]. Examples include live firmware updates and Linux Integrity > Measurement Architecture (IMA). > - We have fully explored the design space. Hence, we believe having it > as a milestone is not required. A comparison of > *pre-/intra-/post-handshake* *attestation* approaches was presented at > UFMRG [3] and RATS [4] in IETF 121, as well as RATS interim [8]. > - The rationale why missing *PKI identity* results in *diversion > attacks* (aka identity crisis) was presented at TLS in IETF 122 [5], > and at RATS interim [6]. I will also present this in detail in UFMRG on > Thursday. > - We have presented potential solutions for *intra-handshake > attestation* at TLS WG in IETF 122 [5] and also implemented one of > them (channel binder [7]), but that needs changes as deep as TLS key > schedule to define new exporters in TLS. The need for channel binders is > argued in [7]. I believe making changes in the TLS key schedule cannot be > done outside of TLS WG. Hence, we keep the charter limited to > *post-handshake > attestation*. > - Binding of Evidence to TLS session is very important otherwise *relay > attacks* are possible. This was presented at RATS interim [6]. > - Regarding the proposed solution in *post-handshake attestation*, I > think we don't need the Exported Authenticators (EA) to be linked to each > other. What was the state of server yesterday (EA1) should be irrelevant to > RP when it checks the state of server today (EA2). I believe it should only > be ensured that exported authenticators are bound to the TLS session, and > this is done already by the Authenticator keys of RFC9261. This is > something we are exploring. > - The WG will give due consideration to privacy in the design. > - Confidential Computing Consortium (CCC) Attestation Special Interest > Group (SIG) [9] will be added to liaison. The formal analysis is already an > adopted project in the SIG. > > If the above does not capture your *technical* questions/concerns, please > clarify it. Please avoid raising *editorial* concerns in this thread. We > will update the charter based on the discussions and get back to you very > soon. > > We will continue discussion of the relevant parts in the relevant WGs/RG: > thanks to secretariat for perfectly time-positioning the BoF and thanks to > respective chairs for accommodating our proposals: > > - TLS WG: Wednesday 16 hrs > - UFMRG: Thursday 14:30 hrs > - RATS WG: Friday 14:30 hrs > > As an individual (i.e., not as proponent): I completely agree that RATS is > unfortunately vague. I keep pushing for more clarity and precision in the > RATS documents and in particular security considerations, but there is > unfortunately only little that an individual can do in this > consensus-driven process :( > > Thank you, > > Usama > > [1] https://ieeexplore.ieee.org/document/10752524 > > [2] > https://datatracker.ietf.org/meeting/120/materials/slides-120-ufmrg-towards-formal-analysis-of-attested-tls > > [3] > https://datatracker.ietf.org/meeting/121/materials/slides-121-ufmrg-specifications-of-attested-tls-00 > > [4] > https://datatracker.ietf.org/meeting/121/materials/slides-121-rats-security-considerations-of-attested-tls-00 > > [5] > https://datatracker.ietf.org/meeting/122/materials/slides-122-tls-identity-crisis-00 > > [6] > https://datatracker.ietf.org/meeting/interim-2025-rats-01/materials/slides-interim-2025-rats-01-sessa-identity-crisis-in-attested-tls-for-confidential-computing-01.pdf > > [7] https://www.usenix.org/conference/atc25/presentation/weinhold > > [8] > https://datatracker.ietf.org/meeting/interim-2025-rats-02/materials/slides-interim-2025-rats-02-sessa-attested-tls-00.pdf > > [9] https://github.com/CCC-Attestation > > [10] > https://datatracker.ietf.org/meeting/123/materials/slides-123-expat-design-space-of-attested-tls-01.pdf > _______________________________________________ > Attested-tls mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
