On Fri, Jul 18, 2025 at 12:45 PM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote:
> (Adding the correct email of expat BoF) > Thanks. I should have checked. > (Also adding RATS since at least my current reply relates more to RATS > than TLS; and folks there may have something to add) > > Thank you once again Ekr. This is insightful and timely. We will discuss > this tomorrow in the Hackathon. The issue is tracked here [1]. Some initial > thoughts inline: > On 18.07.25 19:35, Eric Rescorla wrote: > > > I've now had a chance to look at this draft. > > At a high level I have the same concerns I expressed over > draft-fossati-tls-attestation, which is to say that it unclear what > actual security properties that attestation provides. > > That's a fair point and this time as an author, I fully acknowledge this > shortcoming in our draft. The draft is in early stages. A formal analysis > is ongoing to better characterize the security properties. > > In short, remote attestation will provide Claims about: > > 1. Platform state > - Platform is genuine (and not simulated or emulated). > - Platform is up to date (with all security patches). > 2. Workload state > - Measurements (hashes) of code and memory are as expected. > > And the security properties are: > > - Integrity of Claims (Claims are not modified) > - Freshness of Claims (Claims are not stale) > > This is completely complementary to what TLS provides: > > 1. Service host authenticity > > I'm not sure what you mean by this property. > 1. Extended CA validation > 2. Other PKI policy checks > > TLS does not in fact provide these properties because TLS has no opinion at all about what kind of PKI validation is in play, if any it merely expects that the the peer supply a list of certificates and that the first one be for the end-entity (i.e., that it's key is the one used to sign CertificateVerify). Any other requirements on this certificate are provided by some other piece of context. For instance, in the Web it's the HTTPS binding plus all the PKIX specs. > > and the security properties of TLS are well-defined, e.g., machine > identity, server authentication. > > Hence, we want to preserve the standard TLS properties and in addition, > provide guarantees on the state of the platform and workload. > Yes, this is the level of abstraction I think is insufficient. Let's take a simple example. Consider two TLS implementations, one of which allows the traffic keys to be accessed and one of which does not. These have entirely different security properties from the perspective of the relying party. It's all well and good for the attestation to tell me what code is running on the server, but what is actually needed is guidance in how to translate that into concrete security properties. The more general issue here is that attested TLS -- and attestation generally -- has a very different threat model from ordinary TLS connections. As an intuition pump, consider a system that gathers data from clients and outputs aggregate values (the use case DAP is intended for). In a typical (non-DAP, non-confidential computing) environment, you would make a TLS connection to the server, verify its identity, and then send your data over. This doesn't come with any technical guarantees about how the data is handled, so you're just relying on whatever the privacy policy of the server is. For instance, the operator might say that they don't publish individual values, but you have to just trust them not to. One way to address this problem would be to provide a technical enforcement mechanism by having the server attest to the specific code that it is running, allowing you to (in principle, at least), examine that code and determine whether it actually protects your individual values. However, this changes the threat model dramatically because we now have to worry about the server cheating, i.e., trying to persuade the RP that the operators are unable to access individual values when they really are able to do so. By contrast, in the non-attested case, you just had to trust the server, so there was no question of technically preventing cheating. This brings us to the question of the binding to TLS. As a technical matter, what this mechanism does is bind the operating environment on the peer to the key used to authenticate the peer, but that leaves the person trying to enforce higher-level properties with very little guidance. What properties am I supposed to look at in the code to know if the server operator can in this instance look at individual responses? Because those properties are being provided by TLS (as opposed to, say, encrypting over the top to the TEE), then it's the responsibility of this document to provide some guidance (at minimum). -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
