Subject: [Rats] No root of trust requirement in RATS/EAT

From: Laurence Lundblade <[email-masked]>
Date: Sun, 4 Aug 2019 11:37:38 -0700

An Android phone often looks like this:
  - Linux / Android apps
  - Linux kernel
  - TA’s (Trusted Apps — apps running the TEE)
  - TEE kernel

It must be allowed for any one of these to generate RATS/EAT attestations. It might be that only the Android app generates RATS/EAT attestations. This phone is just one example. Other devices, like cars, may be similar.

If there is a normative or descriptive text saying a root of trust is required to generate an attestation, then we have to redefine root of trust to so that Android apps are roots of trust. This is very counter to the normal definition of root of trust. By common definition the root of trust of the above phone would be the TEE. Such a redefinition for RATS would be very confusing. So I don’t think normative text should require a root of trust.

My second reason is that I don’t think the IETF should set internal security requirements for the internal implementation of an end-point:
The TLS RFC does not require an HSM, even in its very extensive security considerations
COSE mentions keys should be protected, but only as a recommendation and only in security considerations
At the Writing Security Considerations tutorial in Montreal, Yoav Nir said that IETF doesn’t get into end-point security internals so much
Some of my IETF friends tell me SHOULD and MUST are for interoperability aspects of a protocol only

I think it is fine to:
Mention a root of trust as an example
Have lots of text in security considerations about signing key protection
Require a root of trust in profile documents, particularly ones outside the IETF
Have claims that describe the internal security of an entity

I know that large parts of the TCG and TEE worlds have the root of trust as a fundamental part of their architectures. It makes sense there. However, these groups fundamentally work on the security internals of end points. The IETF does not. It focuses on on-the-wire security. Thus, it makes sense that orientations around end-point internal security implementation is different.  Some of what goes in the TCG and TEE worlds doesn’t carry over to the IETF.

I know reorienting the RATS architecture draft to not hinge on roots of trust is a big upheaval, but I think it is necessary.

LL

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 4 Aug 2019 21:12:37 +0200

On 2019-08-04 20:37, Laurence Lundblade wrote:
> If there is a normative or descriptive text saying a root of trust is required to generate an attestation, then we have to redefine root of trust to so that

> Android apps are roots of trust.

Where does this trust come from and how is it delivered to the concerned party?

Android apps are signed but they are not shipped with a private key.

AFAICT it is only the Android OS who can vouch for an app's authenticity.

Anders

> This is very counter to the normal definition of root of trust. By common definition the root of trust of the above phone would be the TEE. Such a redefinition for RATS would be very confusing. So I don’t think normative text should require a root of trust.
> 
>   * The TLS RFC does not require an HSM, even in its very extensive security considerations
>   * COSE mentions keys should be protected, but only as a recommendation and only in security considerations
>   * At the Writing Security Considerations tutorial in Montreal, Yoav Nir said that IETF doesn’t get into end-point security internals so much
>   * Some of my IETF friends tell me SHOULD and MUST are for /interoperability/ aspects of a protocol only
> 
> 
> I think it is fine to:
> 
>   * Mention a root of trust as an example
>   * Have lots of text in security considerations about signing key protection
>   * Require a root of trust in profile documents, particularly ones outside the IETF
>   * Have claims that describe the internal security of an entity
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 4 Aug 2019 21:56:01 -0700

> On Aug 4, 2019, at 12:12 PM, Anders Rundgren <[email-masked]> wrote:
> 

For the definition of an EAT token it doesn’t matter where the trust comes from, just like it doesn’t matter where trust comes from in protocol definitions for TLS, COSE, JWT, CWT and such. The *protocol* definitions do not require or establish trust. They may have a means to do it, but no absolute trust is written into the protocol definition.

I’m pretty sure there’s nothing normative in the TLS protocol definition or other IETF documents that proscribes how the secret key on a TLS server is to be protected. A server implementing TLS could have near zero protection for its private key and still be in compliance with the TLS RFC. That private key could even have been intentionally published and there would still be compliance with the TLS protocol.

To go in a bit further, a definition of root of trust is often “the thing that you have to trust because there is nothing more underlying it to trust”. This definition doesn’t give any absolute sense of trust. It could be a terrible root of trust full of bugs and such. The way you usually avoid that is to make sure your root of trust is certified. That is good and useful in some ways, but we can’t say XX certification from YY organization is required in normative text in a protocol document.

Trust does need to be established (but not through or in protocol definition). Typically who ever receives a token and want to trust it will have some how obtained the necessary public key. They hopefully will also have figured out whether that the whole device side key custody and handling is good enough for their purposes. For example when they get that public key they may come to know that the corresponding private keys are only put in to EAL 5 certified devices.

I really hope that lots of excellent policy and profile documents are written for entity attestation that locks down end-end trustworthiness. FIDO’s certification program is one example. It specifies minimum crypto, key protection, key handling and such for the FIDO-specific attestation it does now. But it is not in the FIDO protocol definition. It is clearly separated.

LL

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 5 Aug 2019 08:21:02 +0200

Hi Laurence,

I still don't get it.  IMHO there must be some kind RoT for an attestation to be of any use.

If the RoT source is weak, buggy, inferior etc. should be out of scope for the specification; it is an application consideration and a part of each RATS/EAT profile.

In TLS the assumption is that private keys are sufficiently protected and that are certificates issued by known (trusted) CAs which is why we trust TLS.
In some TLS installations I have been working with, private keys were indeed mandated to be in HSMs.

Anders

On 2019-08-05 06:56, Laurence Lundblade wrote:
> 
>> On Aug 4, 2019, at 12:12 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 5 Aug 2019 06:38:26 -0400

Chair hat off.

Laurence has an interesting point.  In the PKI space, the IETF defined a
policy profile.  The profile could be filled out however the entity
wanted.  Then it could be audited to meet assurance level requirements that
are defined by NIST.  I'm not sure if the same assurance levels were used
globally or if there are other defined assurance levels.  There are also
levels of authentication defined by NIST as well as levels of identity
proofing.  As it turns out, we did need all of those levels as there were
use cases for each.

To Anders point, why would I want a device with no root of trust?
Plausible deniability perhaps? Lower cost?
Why would I want to sell such a device?  I probably wouldn't and this could
spur on higher level of assurance and remake of devices without this
capability depending on the target market for a device.

If we went this route, which organization should define the assurance
levels?  I'd personally like to see them openly defined and published.
Perhaps it's NIST?

If the IETF were to do this, I wouldn't put it out of scope, but may
require the redefinition of our threat model to speed up.  End point is a
gap in our model that has been raised and talked about quite a bit in
Montreal.  The IETF wouldn't do audits against defined levels, but if
there's only 2 - with and without a root of trust and we left anything more
complex to NIST, TCG, etc., maybe this would be okay.  How it's worded in
the document would matter and if we plainly state it as a definition with
root of trust and without, we may be fine.  In that case, we'd detail out
differences in the security considerations section of a document that did
this.

We had a similar discussion in the IoT space with lighting.  I'd prefer to
see both levels defined along with security considerations rather than rat
hole on the need for always having perfect security.  We are making
deployment progress with ACME (note: it can support any level of
certificate, just requires additional overhead) and other efforts when
there is better security than using nothing, but it may not be perfect.
The bar has been lowered with PM, and as a result, we are seeing better
deployment.

ACME relies on certificate type definitions that are external to the IETF
that are only lightly mentioned in the publications.

Best regards,
Kathleen

On Mon, Aug 5, 2019 at 2:21 AM Anders Rundgren <
[email-masked]> wrote:

> If the RoT source is weak, buggy, inferior etc. should be out of scope for
> the specification; it is an application consideration and a part of each
> RATS/EAT profile.
>
> In TLS the assumption is that private keys are sufficiently protected and
> that are certificates issued by known (trusted) CAs which is why we trust
> TLS.
> >> On Aug 4, 2019, at 12:12 PM, Anders Rundgren <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >>
> >>> It must be allowed for any one of these to generate RATS/EAT
> attestations. It might be that only the Android app generates RATS/EAT
> attestations. This phone is just one example. Other devices, like cars, may
> be similar.
> >>> If there is a normative or descriptive text saying a root of trust is
> required to generate an attestation, then we have to redefine root of trust
> to so that
> >>
> > For the definition of an EAT token it doesn’t matter where the trust
> comes from, just like it doesn’t matter where trust comes from in protocol
> definitions for TLS, COSE, JWT, CWT and such. The *protocol* definitions do
> not require or establish trust. They may have a means to do it, but no
> absolute trust is written into the protocol definition.
> >
> > I’m pretty sure there’s nothing normative in the TLS protocol definition
> or other IETF documents that proscribes how the secret key on a TLS server
> is to be protected. A server implementing TLS could have near zero
> protection for its private key and still be in compliance with the TLS RFC.
> That private key could even have been intentionally published and there
> would still be compliance with the TLS protocol.
> >
> > To go in a bit further, a definition of root of trust is often “the
> thing that you have to trust because there is nothing more underlying it to
> trust”. This definition doesn’t give any absolute sense of trust. It could
> be a terrible root of trust full of bugs and such. The way you usually
> avoid that is to make sure your root of trust is certified. That is good
> and useful in some ways, but we can’t say XX certification from YY
> organization is required in normative text in a protocol document.
> >
> > Trust does need to be established (but not through or in protocol
> definition). Typically who ever receives a token and want to trust it will
> have some how obtained the necessary public key. They hopefully will also
> have figured out whether that the whole device side key custody and
> handling is good enough for their purposes. For example when they get that
> public key they may come to know that the corresponding private keys are
> only put in to EAL 5 certified devices.
> >
> > I really hope that lots of excellent policy and profile documents are
> written for entity attestation that locks down end-end trustworthiness.
> FIDO’s certification program is one example. It specifies minimum crypto,
> key protection, key handling and such for the FIDO-specific attestation it
> does now. But it is not in the FIDO protocol definition. It is clearly
> separated.
> >
> > LL
> >
> >
> >
> >
> >
>

-- 

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 6 Aug 2019 00:49:58 +0000

The RATS charter excludes definition of the endpoint device / trusted device. This is not to say that the endpoint wouldn’t / couldn’t have a root of trust, trusted execution environment (TEE), trusted computing base (TCB) or in some way be trustworthy.  The counter example is also true. The entity that participates in a RATS exchange may not have the trustworthiness properties important to the verifier.

A definition of root of trust is: It is trusted always to behave in the expected manner, because its misbehavior cannot be detected.

By this definition all endpoints are trusted / has a root of trust. The verifier must determine if it is justified in trusting the endpoint based on its root-of-trust definition. For example, if the endpoint defines its root of trust in terms of a software application (only) then the verifier is likely not justified in regarding it as a root of trust, since there are many possible ways to compromise software (in the abstract).

The verifier wants to know something about the entity it is potentially interacting with, therefore it needs a credential that identifies the entity in terms of its construction. The vendor, product, version info is often a reasonable way to do this. The Verifier wants to connect the vendor’s identifier with the entity on the wire, hence the vendor might pre-provision cryptographic keys and issue credentials that allows the verifier to connect the following:

  *   Current entity interaction (session keys, certificate)
  *   Entity type (vendor, product, version)
  *   Entity vendor reputation (trust anchor, certificate)
  *   Cryptographic binding of the above.

Even if these parameters are evaluated by the Verifier, it could still decide there isn’t sufficient basis for non-detection of misbehavior. Maybe because the size of the trusted part of entity has an attack surface that is too large. The verifier might require a root of trust that is smaller or hardened in a particular way. The verifier may require a different component or TEE to be the starting point root of trust, hence it may expect a different (vendor, product, version) entity type as its starting point.

Once a starting point root of trust is established, attestation keys could say additional things about the rest of the endpoint. For example, how it will compute its location and even its current location coordinates.

Some might observe that there are lots of standards/frameworks for encoding location coordinates – that don’t say anything about why the verifier should believe these values. A possible scoping question for RATS might ask whether it makes sense to solve interoperability for the myriad of possible data values that a device could sense vs. focusing more on ‘how’ the device is able to provide values in a way that is believable to the verifier.

I’m not suggesting location coordinates should be out of scope for RATS. Location coordinates are a reasonable context for why a verifier might not believe some other values that are communicated to it. However, if location coordinates are not accompanied by additional claims that explain why it is reasonable to trust their value, the coordinates by themselves don’t equate to attestation. Otherwise, we can point to an IoT framework that encodes location coordinates and call it a day.

-Ned

On 8/5/19, 3:39 AM, "RATS on behalf of Kathleen Moriarty" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Chair hat off.

Laurence has an interesting point.  In the PKI space, the IETF defined a policy profile.  The profile could be filled out however the entity wanted.  Then it could be audited to meet assurance level requirements that are defined by NIST.  I'm not sure if the same assurance levels were used globally or if there are other defined assurance levels.  There are also levels of authentication defined by NIST as well as levels of identity proofing.  As it turns out, we did need all of those levels as there were use cases for each.

To Anders point, why would I want a device with no root of trust?  Plausible deniability perhaps? Lower cost?
Why would I want to sell such a device?  I probably wouldn't and this could spur on higher level of assurance and remake of devices without this capability depending on the target market for a device.

If we went this route, which organization should define the assurance levels?  I'd personally like to see them openly defined and published.  Perhaps it's NIST?

If the IETF were to do this, I wouldn't put it out of scope, but may require the redefinition of our threat model to speed up.  End point is a gap in our model that has been raised and talked about quite a bit in Montreal.  The IETF wouldn't do audits against defined levels, but if there's only 2 - with and without a root of trust and we left anything more complex to NIST, TCG, etc., maybe this would be okay.  How it's worded in the document would matter and if we plainly state it as a definition with root of trust and without, we may be fine.  In that case, we'd detail out differences in the security considerations section of a document that did this.

We had a similar discussion in the IoT space with lighting.  I'd prefer to see both levels defined along with security considerations rather than rat hole on the need for always having perfect security.  We are making deployment progress with ACME (note: it can support any level of certificate, just requires additional overhead) and other efforts when there is better security than using nothing, but it may not be perfect.  The bar has been lowered with PM, and as a result, we are seeing better deployment.

ACME relies on certificate type definitions that are external to the IETF that are only lightly mentioned in the publications.

Best regards,
Kathleen

On Mon, Aug 5, 2019 at 2:21 AM Anders Rundgren <[email-masked]<mailto:[email-masked]>> wrote:
Hi Laurence,

Anders

On 2019-08-05 06:56, Laurence Lundblade wrote:
>
>> On Aug 4, 2019, at 12:12 PM, Anders Rundgren <anders.rundgren.net@gmail..com<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

--

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 5 Aug 2019 19:53:57 -0700

> On Aug 5, 2019, at 5:49 PM, Smith, Ned <[email-masked]> wrote:
> 

This definition is very clear and useful in a trusted computing environment. But note that this definition doesn’t actually say the security of the root of trust is any good (which is counter to the way most use the term). It is just a nice way to label the part that you have to trust.

I find the definition much less useful in network protocol environment. We’re already trusting end points in very big ways. We trust TLS servers to protect their private keys,  encrypting email clients to protect their keys and so on. Maybe we should call them "points of trust”. Most don’t leverage trusted computing architectures we use them all the time even though they have no root of trust. We trust them every day with thousands of dollars of value in stock trading apps and such.

I can’t see what this definition means in a networked protocol environment. It doesn’t seem to elucidate or clarify anything for me.

> By this definition all endpoints are trusted / has a root of trust. The verifier must determine if it is justified in trusting the endpoint based on its root-of-trust definition. For example, if th…

In a way I agree with this.  However I think there are two problems in adopting this view:

1) It is not what most people think. They think it means something like a TPM chip or a TEE or trusted boot. Using the term this way will cause confusion.

2) If a root of trust can be anything, then the term loses its worth. It isn’t saying anything. So why use it?

LL

(I have more comments, but want to take time to think and write…)

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Aug 2019 09:20:45 +0200

> On 6 Aug 2019, at 04:53, Laurence Lundblade <[email-masked]> wrote:
> 

The whole point of the word “trust” is that there is always some leap of faith, being that security is not perfect.  You either trust ARM or Intel or Microchip or whoever to get it right or you don’t.

> I find the definition much less useful in network protocol environment. We’re already trusting end points in very big ways. We trust TLS servers to protect their private keys,  encrypting email cli…

What you describe in the above paragraph is not a choice but a technology limitation.  Is your point that you are seeking a self-asserted root of trust for every system on your network or that you want trust anchored not in the TEE/OS but above those layers?  If so, what’s the value when the OS is hacked?

Eliot

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 6 Aug 2019 09:07:49 -0400

On Tue, Aug 6, 2019 at 3:20 AM Eliot Lear <[email-masked]> wrote:

> This definition is very clear and useful in a trusted computing
> environment. But note that this definition doesn’t actually say the
> security of the root of trust is any good (which is counter to the way most
> use the term). It is just a nice way to label the part that you have to
> trust.
>
>
> The whole point of the word “trust” is that there is always some leap of
> faith, being that security is not perfect.  You either trust ARM or Intel
> or Microchip or whoever to get it right or you don’t.
>

Right, Laurence is pointing out that Ned's definition encompasses systems
without the TEE.  I may be wrong, but it seems that point was missed in
your response.

I still think we can use the level model, where you have levels of security
assertions depending on implementation and point out the differences in
security considerations.  We could establish a profile, like PKI, and then
leave it to another organization to define levels.  We would need to state
risks of choices to have a proper security considerations section to align
with end point security that is likely to be in the IETF's evolved threat
model per Montreal discussions.

Best regards,
Kathleen

> I find the definition much less useful in network protocol environment.
> We’re already trusting end points in very big ways. We trust TLS servers to
> protect their private keys,  encrypting email clients to protect their keys
> and so on. Maybe we should call them "points of trust”. Most don’t leverage
> trusted computing architectures we use them all the time even though they
> have no root of trust. We trust them every day with thousands of dollars of
> value in stock trading apps and such.
>
>
> What you describe in the above paragraph is not a choice but a technology
> limitation.  Is your point that you are seeking a self-asserted root of
> trust for every system on your network or that you want trust anchored not
> in the TEE/OS but above those layers?  If so, what’s the value when the OS
> is hacked?
>
> Eliot
>

-- 

Best regards,
Kathleen

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 6 Aug 2019 13:33:09 +0000

>>> But note that this definition doesn’t actually say the security of 
>>> the root of trust is any good (which is counter to the way most use the term). 
>>> It is just a nice way to label the part that you have to trust.

So this very question ("root of trust is any good") was discussed in the TCG in the 1999-2000 timeframe in the context of what is meant by "trust" (what I now call technical-trust, versus legal-trust or business-trust).  

I think it would be useful for RATS to define *technical-trust* first, before we can decide what's "good" or "bad".

This is what the TCG came-up with:  

-- Something is trusted if:

(a) It does one specific function well (over & over again without change);  (NB. this is where designing the function correctly comes into play).

(b) Operates unhindered  (NB. this is where the non-interference rule & shielded locations feature comes in);

(c) Is able to report the outcome truthfully (NB. this is where the RTR feature comes in).

Example:  we all trust our car-brakes (at least the mechanical ones) because (a) I can open the hood and see the pedal, rods and mechanicals (master cylinder, rotor, pads); (b) I can see that the brake pedal operates/pushes the brake mechanicals; (c) It works every time correctly.

-- thomas --

________________________________________
From: RATS [[email-masked]] on behalf of Kathleen Moriarty [[email-masked]]
Sent: Tuesday, August 6, 2019 9:07 AM
To: Eliot Lear
Cc: [email-masked]; Smith, Ned; Laurence Lundblade; Anders Rundgren
Subject: Re: [Rats] No root of trust requirement in RATS/EAT

On Tue, Aug 6, 2019 at 3:20 AM Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

On 6 Aug 2019, at 04:53, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

Right, Laurence is pointing out that Ned's definition encompasses systems without the TEE.  I may be wrong, but it seems that point was missed in your response.

I still think we can use the level model, where you have levels of security assertions depending on implementation and point out the differences in security considerations.  We could establish a profile, like PKI, and then leave it to another organization to define levels.  We would need to state risks of choices to have a proper security considerations section to align with end point security that is likely to be in the IETF's evolved threat model per Montreal discussions.

Best regards,
Kathleen

Eliot

--

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 6 Aug 2019 19:01:47 +0000

The intent of my previous reply was to have a scoping discussion. The RATS WG likely doesn't have resources / interest / charter to define drafts for every topic relevant to remote attestation. Nevertheless, we can identify the topics we chose not to define and label them so that we have a vocabulary to talk about them (without creating drafts that defines them). 

Laurence's original point was that RoT was something the WG shouldn't define (in a draft) to which I concur. Nevertheless, there is a need to talk about the part of the device (entity) where detection of misbehavior is not possible. This part can't be attested (by definition). If we don't like the term root of trust then we can invent something else. If we go with something like "the-entity-whose-misbehavior-cannot-be-detected", that is longish to type. If we go with root-of-trust then it is something most of the rest of the industry understands is something whose misbehavior can't be detected, though there may be additional connotations. RATS WG has the option of including a terminology section that clarifies for the reader of RATS drafts what properties of the terms we use are most relevant.

Looking at this topic from the perspective of what can be attested, it suggests that the claims attested should be properties where misbehavior can be detected. For example, a hash of firmware A will not describe firmware B as long as the hashing was performed correctly. It may not be possible to detect if the hash of A was performed correctly (since an attacker could have input B and said the output was A) therefore that belongs in the RoT. 

It is a security faux pas to expect the environment reporting attested values can attest to its own security properties. There needs to be finer granularity decomposition to separate what is the RoT functionality from the attestable functionality. Hence, the term 'turtles all the way down'. 

Since the RATS WG scope doesn't anticipate wanting / needing to define specific turtles, working group participants should have something in mind in terms a turtle that is a root of trust and a turtle that is attestable. They can forward claims about the attestable turtle and agree that the root of trust turtle can be identified (e.g. vendor, model, version - and some way to authenticate these values) but it is up to the verifier to have a policy for what it accepts as its root-of-trust turtles. The RoT turtle is the starting point for evaluating the turtles that can be attested. 

-Ned

On 8/6/19, 6:33 AM, "RATS on behalf of Thomas Hardjono" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    
    -- thomas --

    From: RATS [[email-masked]] on behalf of Kathleen Moriarty [[email-masked]]
    
    On Tue, Aug 6, 2019 at 3:20 AM Eliot Lear <[email-masked]<mailto:lear@cisco..com>> wrote:

    This definition is very clear and useful in a trusted computing environment.. But note that this definition doesn’t actually say the security of the root of trust is any good (which is counter to the way most use the term). It is just a nice way to label the part that you have to trust.

    
    
    Best regards,
    Kathleen

    
    Eliot

    --
    
    Best regards,
    Kathleen

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 6 Aug 2019 22:26:37 +0000

Hi Ned,

>>> Laurence's original point was that RoT was something 
>>> the WG shouldn't define (in a draft) to which I concur.

Agree. This would simplify the RATS discussion and drafts tremendously.

>>> it suggests that the claims attested should be 
>>> properties where misbehavior can be detected.

ok, agree -- I think this is typified by most of the use-cases in RATS.

>>> Since the RATS WG scope doesn't anticipate wanting / needing 
>>> to define specific turtles, working group participants should have 
>>> something in mind in terms a turtle that is a root of trust and 
>>> a turtle that is attestable.

So this means that the RATS architecture should assume the existence of a Root of Trust (maybe even an RTM and RTR).

Would it be fair to expect that other RATS drafts to include an assumption statement about their Turtles? (that the draft assumes that an RTM and RTR exists).

-- thomas --

________________________________________
From: Smith, Ned [[email-masked]]
Sent: Tuesday, August 6, 2019 3:01 PM
To: Thomas Hardjono; Kathleen Moriarty; Eliot Lear
Cc: [email-masked]; Laurence Lundblade; Anders Rundgren
Subject: Re: [Rats] No root of trust requirement in RATS/EAT

-Ned

    -- thomas --

    Best regards,
    Kathleen

    Eliot

    --

    Best regards,
    Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 6 Aug 2019 15:41:47 -0700

> On Aug 6, 2019, at 6:33 AM, Thomas Hardjono <[email-masked]> wrote:
> 

I don’t think trust in can be yes-or-no in any kind of absolute sense when considering real world deployment. You can’t say this HW+SW is *always* trusted in every single use case. You probably don’t know all the use cases and attacks. The reality is attackers that might be willing to spend a lot of money (a nation state) or have high motivation (black hats) comes in.

One issue is whether or not there are SW bugs. This can never be determined absolutely. If you spend a lot of money on review, testing and analysis on a simple function, you can get close, but it is not guaranteed. 

Another issue is local HW attacks. Circuit boards can be probed, chips decapped and glitched. Defense against these are expensive and not in common hardware. There are varying degrees of attacks and of defenses, so it is not yes-or-no.

Side channels are another. Could be power, RF, cache timing or such. Here also, there are varying degrees of attacks and of defenses, so it is not yes-or-no.

LL

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 6 Aug 2019 22:54:49 +0000

>>> I don’t think trust in can be yes-or-no in any kind of absolute sense when considering 
>>> real world deployment. You can’t say this HW+SW is *always* trusted in every 
>>> single use case. You probably don’t know all the use cases and attacks. 
>>> The reality is attackers that might be willing to spend a lot of 
>>> money (a nation state) or have high motivation (black hats) comes in.

Yes of course. I don't think I was claiming there is an absolutely secure  HW+SW that is *always* trusted in single use case. No one in security industry has ever claimed this.

Everything can be cracked, but that doesn't mean we should not use "trusted H/W" like the TPM.  This is why the notion of the TCB was developed (Orange Book), but this is a separate discussion.

>>> One issue is whether or not there are SW bugs. 
>>> This can never be determined absolutely. 
>>> If you spend a lot of money on review, testing and analysis 
>>> on a simple function, you can get close, but it is not guaranteed.
>>> 
>>> Another issue is local HW attacks. Circuit boards can be probed, 
>>> chips decapped and glitched. Defense against these are expensive
>>>  and not in common hardware. There are varying degrees of attacks 
>>> and of defenses, so it is not yes-or-no.
>>> 
>>> Side channels are another. Could be power, RF, cache timing or such. 
>>> Here also, there are varying degrees of attacks and 
>>> of defenses, so it is not yes-or-no.

@Laurence:  Thank you for this great explanation :-)

-- thomas ---

________________________________________
From: Laurence Lundblade [[email-masked]]
Sent: Tuesday, August 6, 2019 6:41 PM
To: Thomas Hardjono
Cc: Kathleen Moriarty; Eliot Lear; [email-masked]; Smith, Ned; Anders Rundgren
Subject: Re: [Rats] No root of trust requirement in RATS/EAT

On Aug 6, 2019, at 6:33 AM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 6 Aug 2019 16:23:22 -0700

> On Aug 6, 2019, at 3:54 PM, Thomas Hardjono <[email-masked]> wrote:
> 

So, not sure what you mean by ‘use “trusted H/W” like the TPM’. It could mean:

1) TPM chips are good and useful things for the world to use. I agree.

2) The term ‘trusted H/W’ has clear meaning. I disagree per my previous comments about degree.

3) We should use the term ‘trusted H/W’ in the RATS architecture document. I disagree because of 2) above and other comments.

I think ‘trusted’ can be yes-or-no in specific use cases where requirements and the threat model are clearly set and determined, but we are not working on one of those. Our attestation work has to span from use cases that only stand up to lame wanna be hackers to use cases that stand up to nation states.

LL

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Aug 2019 09:40:18 +0200

Hi,

> On 7 Aug 2019, at 01:23, Laurence Lundblade <[email-masked]> wrote:
> 
> 

I would go further.  While I agree that there are no certainties, at the end of the day RATS provides values asserted by a particular entity that is authenticated via a root of trust for various purposes, some of which are likely to be automated, like anomaly detection, remediation management, etc.  That automation demands a small number of return values in its evaluation (e.g., expected, unexpected, and whether or not to trust the results).  The latter will require external configuration in advance.  The answer can only be yes or no.  If it is no, an exception process will kick in.  At that point a human will get involved.  The more a human has to get involved in that decision process, the less use the system will be.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Aug 2019 12:24:44 +0000

There are two aspects here:

  *   What is specified in terms of interoperability
  *   What is described as part of the bigger picture.

IETF specifications, as you correctly noted below, do not specify many aspects of the big picture. While there are some documents that try to describe them as part of architecture documents IETF documents never go into the details of most things.

IMHO EAT tokens should specify how the claims look like and not worry about the rest too much. This includes not to worry about the root of trust.
The architecture document can and should talk about the bigger picture but not mandate a specific deployment or implementation.

Isn’t it simple?

Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Sonntag, 4. August 2019 20:38
To: [email-masked]
Subject: [Rats] No root of trust requirement in RATS/EAT

  *   The TLS RFC does not require an HSM, even in its very extensive security considerations
  *   COSE mentions keys should be protected, but only as a recommendation and only in security considerations
  *   At the Writing Security Considerations tutorial in Montreal, Yoav Nir said that IETF doesn’t get into end-point security internals so much
  *   Some of my IETF friends tell me SHOULD and MUST are for interoperability aspects of a protocol only

I think it is fine to:

LL
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Simon Frost <[email-masked]>
Date: Wed, 7 Aug 2019 15:44:47 +0000

> I think ‘trusted’ can be yes-or-no in specific use cases where requirements and the threat model are clearly set and determined, but we are not working on one of those. Our attestation work has to…

Perhaps it’s appropriate then that the Use Cases document is annotated with expectations of Trust or interpretations of RoT per use case rather than putting an over generalisation into the Architecture spec?

From: Laurence Lundblade <[email-masked]>
Sent: 07 August 2019 00:23
To: Thomas Hardjono <[email-masked]>
Cc: [email-masked]; Kathleen Moriarty <[email-masked]>; Smith, Ned <[email-masked]>; Eliot Lear <[email-masked]>; Anders Rundgren <[email-masked]>
Subject: Re: [Rats] No root of trust requirement in RATS/EAT

On Aug 6, 2019, at 3:54 PM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 7 Aug 2019 08:47:28 -0700

> On Aug 6, 2019, at 6:07 AM, Kathleen Moriarty <[email-masked]> wrote:
> 

Here’s a description of what we’ve done in FIDO for certification levels. It’s just one example, but an interesting one because it spans lots of technologies (TEEs, SGX, secure elements, Linux, Windows, standalone USB tokens and so on) and a wide range of security and use cases. The FIDO protocol includes attestation.

Three main levels are defined. Then there is a “+” modifier for each level:

L1: There are no hardware or system software requirements at all. A FIDO authenticator running anywhere can be certified. To a large degree this is about just trusting the hardware and software from the device / platform vendor. Cost to certify is under $10,000.

L2: There must be some sort of restricted operating environment like a TEE, SGX, secure element or such. The FIDO authenticator can’t be running in an environment like Linux or MacOS. A certification lab must be engaged. The cost to certify is vaguely around $100,000 (mostly lab fees).

L2+: The restricted operating environment (TEE or such) and authenticator application must be certified. This can be quite expensive, but typically the TEE or such will already have been certified.

L3: In addition to L2+, there must be defenses against hardware attacks at the circuit board level. This might be just a multi-layer PCB, potting or a really difficult to open enclosure. L3 is intended to defend against devices that have physically been captured by the attacker. 

L3+: In addition there must be defenses against chip-level attacks. Smart cards and secure elements have these defenses today.

You could say that L1 is kind of “best practice”, L2 is about reduced attack surface to address network-born scalable attacks and L3 adds HW defenses to deal with a lost phone or such that the attacker tries to disassemble. Different use cases need different levels of protection.

Certification programs is typically are set up with three participants to prevent collusion:
1) Many vendors of technology, the ones being certified
2) Several qualified certification labs that do the evaluation
3) A single issuer / overseer of the certification program

In the case of FIDO, the FIDO Alliance is the overseer. They collect fees, qualify labs, set requirements and issue the certifications. They very explicitly have a committed to do this with staff, legal and financial structure. Things like revocations, expiration and dispute policy are addressed.

More info is here <https://fidoalliance.org/certification/> and here <https://fidoalliance.org/certification/authenticator-certification-levels/>.

A main point is that there is a big range here. There is degree. There is no binary trust decision.

LL

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 12:09:24 -0400

This discussion about Root of Trust seems silly.

There are no absolute trusts.

  All paths of trust start from a local trust anchor in the verifier and/or
  relying party. They are *ALL* circles of signed statements (whether claims
  or certificates)

There is no need to invoke an infinity of turtles.

(Rivert and co. said this in SDSI/SPKI in RFC2692/2693 and in a number of
papers.)

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 12:13:11 -0400

Simon Frost <[email-masked]> wrote:
    >> I think ‘trusted’ can be yes-or-no in specific use cases where
    >> requirements and the threat model are clearly set and determined, but
    >> we are not working on one of those. Our attestation work has to span
    >> from use cases that only stand up to lame wanna be hackers to use
    >> cases that stand up to nation states.

    > Perhaps it’s appropriate then that the Use Cases document is annotated
    > with expectations of Trust or interpretations of RoT per use case
    > rather than putting an over generalisation into the Architecture spec?

Are you saying that each use case should indicate what kind of trusted
path is required?  If so, then I agree.

Based upon the feedback at IETF105, I have a bunch of similar use cases
which are probably distinguished by the kinds of trust, or perhaps degree of
paranoia^W^W^Wlevels of assurance required.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 12:20:03 -0400

> IETF specifications, as you correctly noted below, do not specify many
    > aspects of the big picture. While there are some documents that try to
    > describe them as part of architecture documents IETF documents never go
    > into the details of most things.

I agree with you strongly.

Where I think we are getting into trouble is that
1) our charter says that we can go beyond just documenting the
   (interoperable) claims into designing a transport protocol,
   and I think that the details of that start to be attractive nuissances.

2) it might be that some want to have different claims that differ only
   in their degree of assurance.  That is, there is a difference between:

   "Little Bobby said the babysitter said that Sarah could watch the scary
            movie on TV"
 vs
   "Little Bobby has a note from Mom that says that Sarah could watch
           the scary movie on TV"

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 12:24:51 -0400

Laurence Lundblade <[email-masked]> wrote:
    > Here’s a description of what we’ve done in FIDO for certification
    > levels. It’s just one example, but an interesting one because it spans
    > lots of technologies (TEEs, SGX, secure elements, Linux, Windows,

Would these different levels (L1,L2,L3,+) be visible in claims two layers
away?

For instance, would the recipient of funds transfer be able to see how the
authorization was attested to by the senders' bank?

---

From: Simon Frost <[email-masked]>
Date: Thu, 8 Aug 2019 07:54:33 +0000

> Are you saying that each use case should indicate what kind of trusted path is required?  If so, then I agree.
Yes, that was my intention.

Cheers
Simon

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: 07 August 2019 17:13
To: Simon Frost <[email-masked]>; [email-masked]
Subject: Re: [Rats] No root of trust requirement in RATS/EAT

    > rather than putting an over generalisation into the Architecture spec?

Are you saying that each use case should indicate what kind of trusted path is required?  If so, then I agree.

Based upon the feedback at IETF105, I have a bunch of similar use cases which are probably distinguished by the kinds of trust, or perhaps degree of paranoia^W^W^Wlevels of assurance required.

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

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 9 Aug 2019 01:09:54 +0000

The assumption is "mom" has more credibility/authority than "babysitter" to claim that "scary movie on TV" is a trustworthiness property. 

The Verifier needs to have a policy(?) that recognizes mom as having more credibility than babysitter since its reasonable (within the use case context?) for both to make the same claim. 

On 8/7/19, 9:20 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 9 Aug 2019 09:40:20 -0700

Hi Ned,

> On Aug 6, 2019, at 12:01 PM, Smith, Ned <[email-masked]> wrote:
> 

My original point is that RATS should not put any requirements on implementation.

If a root of trust is required, that will imply HW security requirements on the implementation for most people
If we redefine root of trust so that it doesn’t imply any requirements on the implementation, we will confuse
We MUST allow generation of attestations from subsystems other than the-entity-whose-misbehavior-cannot-be-detected
Implementation requirements would be a large divergence from most other IETF-defined protocols like TLS and COSE

Maybe we can just call it the “attester” and say that it is the thing that has the attestation signing key and generates the attestation. Say that in many cases, particularly those with better security, the attester will be what is traditionally known as a “root of trust”. Some implementation profiles will require a root of trust.

> Looking at this topic from the perspective of what can be attested, it suggests that the claims attested should be properties where misbehavior can be detected. For example, a hash of firmware A wi…

The real basis for attestation trust is actually out-of-band trust establishment between the relying party and manufacturer or such as I’ve tried to illustrate in my recent hypothetical example.  It seems to me that the real trust in TLS is established out of band through the download of a web browser containing roots by the end user. This is similar. 

> 
> It is a security faux pas to expect the environment reporting attested values can attest to its own security properties. There needs to be finer granularity decomposition to separate what is the RoT functionality from the attestable functionality. Hence, the term 'turtles all the way down’.

There is a non-turtle in the out-of-band interaction. 

> Since the RATS WG scope doesn't anticipate wanting / needing to define specific turtles, working group participants should have something in mind in terms a turtle that is a root of trust and a tur…

For TPMs and the TCG I think there may be a non-turtle out-of-band interaction that is tacitly assumed and baked into "root of trust”. The TCG sharply defines the functionality and security of the TPM. TPM vendors all precisely adhere to this. There is also a strong HW-oriented Common Criteria certification program. I think there are also conventions for key distribution the TPM world. A TPM vendor diverging from this wouldn’t sell any product so all of this is ever-present and uniform. (I’m not a TPM expert, so hopefully I have got this right).

Seems like the GP / TEE world has some of this too, though not as much.

I am aiming for RATS applicable in a broader way with no tie to implementation security. The same sort of broadness that TLS has.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 9 Aug 2019 22:44:15 +0000

See my comments inline [nms].

On 8/9/19, 9:41 AM, "RATS on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Ned,

On Aug 6, 2019, at 12:01 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

My original point is that RATS should not put any requirements on implementation.
[nms] I infer you mean RATS should not put any trust requirements on implementation?
[nms] The charter text is careful to use the phrase ‘trustworthiness’ rather than ‘trust’. The architecture draft tries to avoid using ‘trust’ and ‘trusted’. The motivation for using ‘trustworthiness’ and ‘trustworthiness properties’ is to focus energy on identifying things (claims) that can be concretely expressed (as data structures) and as statements that are obvious and factual. The word ‘trust’ tends to evoke ideas that seem to be subjective or open to interpretation. Thomas Hardjono mentioned in a previous thread the differences between social and technical trust. I recommend review of https://www.w3.org/2016/04/blockchain-workshop/slides/Hardjono-Pentland-W3C-June2016.pdf to anyone interested in digging deeper. The word ‘trust’ may evoke ideas that are more correlated with ‘social trust’ while the RATS charter and other documents are trying to focus on ‘technical trust’.

·         If a root of trust is required, that will imply HW security requirements on the implementation for most people
·         If we redefine root of trust so that it doesn’t imply any requirements on the implementation, we will confuse
·         We MUST allow generation of attestations from subsystems other than the-entity-whose-misbehavior-cannot-be-detected
·         Implementation requirements would be a large divergence from most other IETF-defined protocols like TLS and COSE

Maybe we can just call it the “attester” and say that it is [2]the thing that has the attestation signing key and generates the attestation. Say that in many cases, particularly those [3]with better security, the attester will be what is traditionally known as a “root of trust”. Some implementation profiles will require a root of trust.
[nms] [1] The RATS architecture (is trying to) define attestation roles such as Attester, Verifier etc.. and actors such as Device, Supply Chain Entity, Service Provider etc… Referring to [2] “thing” is stereotyped as a ‘device’ actor in the architecture draft so that performance of the Attester role doesn’t carry with it any baggage or assumptions about actor (aka device) composition or trust. The Attester role does seem to have some semantics regarding what it can say (claim) vs. what should be claimed by an Asserter (aka Claimant). In other words, self-assertion (e.g. “I’m trustworthy because I said so”) doesn’t seem reasonable (logical). The architecture draft uses the term ‘root of trust’ to describe a decomposition of the device (actor) into more primitive device components (sub-actors?) so that it is possible for the Attester to avoid becoming a self-asserter.

Specific to your statement above in [3]. The Attester can make lots of claims legitimately and sign them using its attestation key. However, it can’t make claims about the signing key because the key itself is speaking (attesting). Some other entity (actor) needs to assert claims about the trustworthiness properties of the Attester’s key. Maybe it is a second Attester or maybe it is an Asserter. If the Asserter is a supply chain entity that manufactured the key so that it resists certain attacks then the supply chain entity should say that. If the Attester tries to say the same thing about its key, the Verifier should be suspicious. How can a key be cognizant of the manufacturing process that created it?

Maybe different terminology besides root of trust will be helpful?

Nevertheless, the architecture and other drafts should be careful not to describe things that are insecure (illogical?) by design. Ultimately, the degree (strength-of-function) to which an actor is worthy of being considered trusted is somehow embodied in the policies affecting either Verifier or Relying Party responses to attestation results. The intent of the architecture draft is that the Attester role doesn’t imply any particular strength-of-function to be considered an Attester. It also isn’t trying to imply that there is no such thing as strength-of-function (or whatever words we use to capture the idea of level of implementation hardening and/or resistance to attack).

[nms] Using the roles terminology architecture draft you appear to be saying the following:
“The basis for believing evidence from the Attester (by the Verifier or Relying Party) is actually tied to an out-of-band flow of Assertions from one or more Asserters.”
This makes sense and resonates with what is depicted in the architecture diagrams and in the architecture draft.  Definition of flows to and from the Asserter (claimant) are currently out of scope for the WG but will be described in the architecture draft. Your point seems to be that Verifier / Relying Party depends on this out-of-band flow in order to arrive at any sort of meaningful conclusion about trustworthiness of evidence. To which I fully agree.

There is a non-turtle in the out-of-band interaction.
[nms] The security faux pas is referring to [1] in this email. ‘Turtles’ refers to ‘sub-actors’ in [1]. Yes, in addition to the device / device components (aka actor / sub-actors) there will also be supply chain entities (actors) performing the Asserter role who supply Assertions out-of-band(?) to the Verifier (and maybe Relying Party). Assertions are used to compare / evaluate Attester signed Evidence as well as claims made by Asserters. To be precise, the sub-actor that uses the attestation key implements the Attester role and the sub-actor that protects the attestation key is what the arch draft calls ‘root of trust’. The Assertions from Asserters contain claims about the ‘root of trust’ sub-actor while claims from the other sub-actor are Evidence.

For TPMs and the TCG I think there may be a non-turtle out-of-band interaction that is tacitly assumed and baked into "root of trust”.. The TCG sharply defines the functionality and security of the TPM. TPM vendors all precisely adhere to this. There is also a strong HW-oriented Common Criteria certification program. I think there are also conventions for key distribution the TPM world. A TPM vendor diverging from this wouldn’t sell any product so all of this is ever-present and uniform. (I’m not a TPM expert, so hopefully I have got this right).
[nms] The TCG does define a common criteria process. However, not all implementations of a TPM receive certifications or branding. There are open source software implementations of TPM functionality that could be used to perform an attestation protocol. TCG attestation verifiers shouldn’t assume the attestation is believable simply because the attestation protocol was followed.

The TCG attestation mechanism does define a common criteria claim. Normally, this claim is asserted by a TPM manufacturer (e.g. the vendor’s key signs it) not a TPM attestation key.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 9 Aug 2019 19:02:19 -0700

> On Aug 9, 2019, at 3:44 PM, Smith, Ned <[email-masked]> wrote:
>  

The mainline RATS documents should have no security requirements or strength-of-function requirements on the implementation roughly meaning:
No requirement for how well it protects the signing key from SW attacks, HW attacks, side channels and such
No requirement that the owner of the device can’t replace the SW or change the keys (no secure / trusted boot)
Other similar...

Protocol requirements are obviously necessary. Security recommendations are fine (but not MUSTs or SHOULDs).

…skipping the complex discussion on trust and roles for now.

> Maybe different terminology besides root of trust will be helpful?

I think it is necessary. It should be defined in the architecture document.

The roles in the architecture document are not clear to me yet. “Attester” seemed the closest.

>  
> ...The intent of the architecture draft is that the Attester role doesn’t imply any particular strength-of-function to be considered an Attester. It also isn’t trying to imply that there is no such thing as strength-of-function (or whatever words we use to capture the idea of level of implementation hardening and/or resistance to attack).

Agree with this.

> This makes sense and resonates with what is depicted in the architecture diagrams and in the architecture draft.  Definition of flows to and from the Asserter (claimant) are currently out of scope for the WG but will be described in the architecture draft. Your point seems to be that Verifier / Relying Party depends on this out-of-band flow in order to arrive at any sort of meaningful conclusion about trustworthiness of evidence.

Yes.

It seemed like to some that requiring a root of trust solves this problem of trust. I was bringing up the out-of-band flow to show how trust is really established.

> To which I fully agree.

LL

---

From: Ira McDonald <[email-masked]>
Date: Sat, 10 Aug 2019 08:28:23 -0400

Hi,

I agree with Laurence that this (usually ignored) out-of-band flow of
configuration information for keys, key usage, and "trustworthiness"
attestation context is important to recognize in RATS architecture
(and to mention in RATS information model).

Ned correctly quoted the essence of the US NIST definition of an RoT
earlier in this thread.

But I've always strongly disliked that definition, because it consists of
saying one thing about whats NOT true about an RoT (never use a
negative in a definition is a good rule of thumb).  But it says nothing
about what functionality an RoT *does* provide.

It's true that a Verifier always does make a binary decision about
instantaneous "trustworthiness".  So what.  That decision might
well be different a moment later or for a different requested access
or operation permission.

The historic focus (not just in TCG) on the value of "secure boot" is
pretty irrelevant for a server (or mobile phone) that booted up months
ago.  It's only the *current* state of the Attester's device or application
that's actually useful.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Aug 9, 2019 at 10:02 PM Laurence Lundblade <[email-masked]>
wrote:

> The mainline RATS documents should have no security requirements or
> strength-of-function requirements on the implementation roughly meaning:
>
>    - No requirement for how well it protects the signing key from SW
>    attacks, HW attacks, side channels and such
>    - No requirement that the owner of the device can’t replace the SW or
>    change the keys (no secure / trusted boot)
>    - Other similar...
>
>
> ...The intent of the architecture draft is that the Attester role doesn’t
> imply any particular strength-of-function to be considered an Attester. It
> also isn’t trying to imply that there is no such thing as
> strength-of-function (or whatever words we use to capture the idea of level
> of implementation hardening and/or resistance to attack).
>
>
> Agree with this.
>
>
> Looking at this topic from the perspective of what can be attested, it
> suggests that the claims attested should be properties where misbehavior
> can be detected. For example, a hash of firmware A will not describe
> firmware B as long as the hashing was performed correctly. It may not be
> possible to detect if the hash of A was performed correctly (since an
> attacker could have input B and said the output was A) therefore that
> belongs in the RoT.
>
>
> The real basis for attestation trust is actually out-of-band trust
> establishment between the relying party and manufacturer or such as I’ve
> tried to illustrate in my recent hypothetical example.  It seems to me that
> the real trust in TLS is established out of band through the download of a
> web browser containing roots by the end user. This is similar.
>
> “The basis for believing evidence from the Attester (by the Verifier or
> Relying Party) is actually tied to an out-of-band flow of Assertions from
> one or more Asserters.”
>
> This makes sense and resonates with what is depicted in the architecture
> diagrams and in the architecture draft.  Definition of flows to and from
> the Asserter (claimant) are currently out of scope for the WG but will be
> described in the architecture draft. Your point seems to be that Verifier /
> Relying Party depends on this out-of-band flow in order to arrive at any
> sort of meaningful conclusion about trustworthiness of evidence.
>
>
> Yes.
>
> It seemed like to some that requiring a root of trust solves this problem
> of trust. I was bringing up the out-of-band flow to show how trust is
> really established.
>
> To which I fully agree.
>
>
>
> LL