[Rats] Attestation of implementation vs authenticity of service

[Laurence Lundblade <[e-mail]>]

This is to introduce discussion about the use of TLS/HTTPS versus Attestation. I’ve seen a few places where Attestation is being proposed for use where I think TLS/HTTPS is probably sufficient or a better fit.

Reviewing the trust relationships described in the architecture document got me thinking about sharpening a distinction between device attestation (e.g., EAT for phone) and service authenticity (e.g. HTTPS for a web site):

Device Attestation
Focus is on the implementation, the HW and SW
The legal entity of interest is the device manufacturer
The claims are about the HW and the SW, not the device owner
Example: a mobile phone (not its owner/user)
Example: integrity of a remote device

Service Authenticity
Focus is on the provider of the service, not the HW or SW
The legal entity of interest is the service provider
There is no equivalent of claims, but if there was they would be about the business or person operating the service
Example: a web site
Example: an email provider (IMAP service)

Service providers (e.g., web sites) use whatever HW and SW they want to use. As a user of the service we don’t care what HW and SW they select. We trust the service provider to pick good HW and SW and to configure and operate it correctly. They might change the HW and the SW and as a user we won’t know.  For example we trust Bank of Xxx to operate their banking web site correctly with little concern for their HW. This is why attestation of the HW and SW is not so useful to the user of a service.

Users of mobile phones and IoT devices are not trustworthy to pick secure HW and SW. They are not professionals like the people running web sites. There is little accountability against them if they pick bad SW and HW. Therefor we want attestation for these usage scenarios. This is why EAT, FIDO and Android Attestation exist.

I don’t think the line between device attestation and service authenticity is completely black and white. In some use cases attestation may be bent to provide some service authenticity. But I don’t think it makes sense to add attestation to the millions of web sites out there, add support for it to browsers and make attestation an extra layer of security for web browsing.

I think it is fine for a service provider to use attestation inside their service to monitor integrity and such of the HW and SW providing the service. But usually that won’t be manifest outside the service. It could be awkward for the user to the service to have to re evaluate the service every time the service provider changes HW.

Another way to look at this is from a certification / regulatory view. If the thing you're looking at is a candidate for implementation certification such as Common Criteria, FIPS, FIDO certification, then it probably lines up with device attestation. On the other hand, if the thing your are looking at lines up with regulation (e.g., banking regulation, GDPR,...) and to some degree OWASP <https://owasp.org/>, then it probably lines up with service authenticity. 

I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not, for example saying something like “attestation is not a replacement or augmentation for HTTPS/TLS"

I think the RATS architecture should be clear which of its components are services and which are targets of attestation. In particular, I think the Verifier and Endorser/Manufacturer are services and that service authenticity is more appropriate for them than attestation (I would consider a signed Endorsement a form of service authenticity).

LL