Subject: [Rats] Attestation of implementation vs authenticity of service

From: Laurence Lundblade <[email-masked]>
Date: Mon, 3 Aug 2020 11:58:58 -0700

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 3 Aug 2020 19:03:25 +0000

*   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://urldefense.proofpoint.com/v2/url?u=https-3A__owasp.org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=i2HHx7M5shXvUZmbo2H9JWFNah1cQYR9QL8xSUTJHcw&s=D7ncLvRq-bcYsr722qYkwbNUSyi2i1Ap7rstjSY-zZ0&e=>, then it probably lines up with service authenticity.

That is a *very* interesting way to slice things; I’ll have to think about it more. Thanks!

  *   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"

Excellent point.  Doing so will likely avoid a round-trip with the security AD’s.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 3 Aug 2020 20:46:59 -0400

Hi,

+1 to Laurence's insight here on Attestation for Devices versus
TLS/HTTPS for Services.

Cheers,
- Ira

On Mon, Aug 3, 2020 at 3:03 PM Salz, Rich <rsalz=[email-masked]>
wrote:

>
>    - 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://urldefense.proofpoint.com/v2/url?u=https-3A__owasp.org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=i2HHx7M5shXvUZmbo2H9JWFNah1cQYR9QL8xSUTJHcw&s=D7ncLvRq-bcYsr722qYkwbNUSyi2i1Ap7rstjSY-zZ0&e=>,
>    then it probably lines up with service authenticity.
>
>
>
> That is a **very** interesting way to slice things; I’ll have to think
> about it more. Thanks!
>
>
>
>    - 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"
>
>
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Aug 2020 13:47:09 +0200

On 2020-08-03, at 20:58, Laurence Lundblade <[email-masked]> wrote:
> 
> 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)
> 

Hi Laurence,

if you are talking about HTTPS, there is exactly one claim:  The service is speaking for a specific name (e.g., facebook.com).  All other claims are funneled through this one very special one.  Of course, the TLS handshake could be leveraged to do more than this one claim, but that is not what happens in HTTPS.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 5 Aug 2020 12:42:30 -0700

> On Aug 5, 2020, at 4:47 AM, Carsten Bormann <[email-masked]> wrote:
> 

Yes, agreed.

Any notion of trustworthiness, regulatory compliance and such for a service is implied. We make heavy use of that implication and that is mostly OK. For example, knowing that facebook.com is Facebook Inc allows us to assume lots about the service from what we know of the company. 

The equivalent for attestation would be just to name the manufacturer of the HW or SW. However, we are going far beyond that with all the Claims in the Evidence and Results.

Maybe we should have Claims about services? For example, what regulatory statutes they meet. Where are they incorporated. A reference to their terms of service and privacy policy.

That however seems like a new WG, not RATS.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 6 Aug 2020 18:38:44 +0000

The RATS charter refers to "system component" as the initial focus for definition; which includes claims definition. The architecture makes it clear that claims can originate elsewhere as well. It seems reasonable that claims about services could be defined elsewhere, but still be conveyed / appraised using RATS WG defined architecture and technology. Alternatively it could be defined in RATS, but possibly with some charter adjustments to allow "services" scope?

-Ned

    Yes, agreed.

    LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 6 Aug 2020 12:09:50 -0700

Yes, the RATS architecture seems highly applicable to claims-about-services (for lack of a better term). It would be dumb to have an IETF architecture for claims-about-services that didn’t re use the RATS architecture at least partially.

By my read of the charter, claims-about-services are not explicitly excluded, but also not quite in the spirit of it. Maybe the work done is done in RATS with a re charter?

The bottom line for me, is that I really don’t want to put any claims about services in EAT. There is enough work to do already :-)

LL

> On Aug 6, 2020, at 11:38 AM, Smith, Ned <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Aug 2020 21:10:51 -0400

Laurence Lundblade <[email-masked]> wrote:
    > 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.

The only reason that I do not demand knowledge (attestation) about how my
Bank operates is because I don't (individually) have the economic clout to demand it, and
the users suffer from a Collective Action Problem
  https://www.britannica.com/topic/collective-action-problem-1917157
  https://en.wikipedia.org/wiki/Collective_action_problem
In Canada (at least), as a shareholder of a publically trade company, I'm
apparently forbidden from communicating with other shareholders, except via the
company.

So I don't think that the difference has anything to do with what we want,
but rather what has been possible up to now.

My bank regularly makes very poor technology choices.
They also seem very reluctant to publically document their processes.
Unfortunately, I can't vote with my wallet, because the other ones are as bad or worse.

    > 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.

This does not ring correct at all to me.
Large media giants want assurances from manufacturers of phones that the end
user does not have control over the video output systems, and the large
suppliers have demanded (again, through massive differences in economic
clout) assurances.
It has nothing to do with the abilities of the owners.
In fact, what is desired is assurance that the owners have in fact been
forced not to pick their own SW.

Carsten Bormann <[email-masked]> wrote:
    > if you are talking about HTTPS, there is exactly one claim:  The
    > service is speaking for a specific name (e.g., facebook.com).  All
    > other claims are funneled through this one very special one.  Of
    > course, the TLS handshake could be leveraged to do more than this one
    > claim, but that is not what happens in HTTPS.

The CA system could also review the Bank's systems on a regular basis.
Claims could be embedded in the HTTPS server certificate, and this is already
in the architecture, in the spider diagram.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Aug 2020 15:29:52 +0200

Hi Laurence,

I am fine with "no Claims exclusive for services" in the base EAT I-D. 
One can always start a complementary I-D that focuses on services later 
(e.g. facilitated by re-chartering).

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 18 Aug 2020 12:25:50 -0700

> On Aug 15, 2020, at 6:10 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Collective action for banks exists in a big way in the form of government regulation. For other services its usually reputational. Facebook’s isn’t so good right now. We all seem to trust GitHub well enough based on reputation.

Most folks decide to trust services based on reputation - what we read in the news, what we hear from friends and such. Sometimes we want to see if they meet government regulations, have deposit insurance or such. Sometimes we read the terms of service (which are scary for a bank), but mostly we don’t. 

I’m thinking about general population here, not super-smart IETFers or lawyers that read terms of service.

But I doubt even us IETFers would care if GitHub switched from Intel to ARM CPUs or from Azure to AWS. We mostly trust Microsoft to run GitHub well.

> forced not to pick their own SW.

My characterization was coarse.
- End users don’t get to choose much about the OS on a phone, maybe when to upgrade
- Some areas of devices are particularly locked down — video playback, authentication, payments (e.g. Apple Secure Enclave).
- End users do get to choose which apps they install
   - But only from an approved list
- Some end users get to use debug modes and write their own code, but when they do apps and services are disabled or they are fenced off.

I think it does have to do with the end users.

In China, the app ecosystems are a lot more wild-west than the US. There are imposter apps trying to dupe people into using them.

If I lose half the money in my bank account through a mobile app problem, I’m going to blame the bank and the bank might even be liable. The bank doesn’t want anyone accessing their online banking with anything but their app (and a browser).

Or consider allowing end users to write their own FIDO authenticators or use any authenticator available for download. Maybe one is branded as “easy FIDO” and truly is easier than most so it gets a lot of users. But underneath it is allowing the a foreign enemy nation to collect private info on citizens.

Allowing the masses unconstrained choices of SW for to access high-value services opens the door to fakes, frauds, getting duped and such.

LL