On 22.07.25 10:35, Mark Novak wrote:
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,
"no changes in TLS" is already covered in charter.
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.
The protocol should be as much agnostic to use cases as possible. "Some of the uses may /not/ need it" is insufficient of an argument for me to skip this requirement. Why did we not design TLS without replay protection? If you can provide me a good answer, I am happy to remove this requirement.
Besides, continuous posture assessment requires multiple attestation rounds on the same connection. Hence, replay protection is important there.
See ref. [1] for further arguments.
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.
seems completely irrelevant to what we are doing here.
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”.Where is it coming from? We are not introducing any service. It's a direct client-server connection.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.Attestation is /not /part of secure channel establishment. Remote attestation part is done over an established secure channel.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.
It doesn't have to. The WG can decide this later on.
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.
Implementation detail, irrelevant to the charter.
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.
Implementation detail, irrelevant to the charter.
[1] https://ieeexplore.ieee.org/document/10752524
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
