Subject: [Rats] regarding rats-network-device-attestation

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Sep 2019 12:04:30 +0100

I have read through this document, and it is now the publically available reference
on the TCG work for the use-case document.  I have sent some edits directly
to the authors.

I like the use of the term "Remote Integrity Verification".
I'm not too crazy about "RIV" as a TLA in a field with way too many TLAs
already though, but okay.

I found this text difficult:

         * Platform Identity refers to the mechanism assuring the
        attestation verifier (typically a network administrator)
        that the equipment on their network can be reliably identified,
        and that its manufacturer is certified by a trusted authority.

}        This certification provides the verifier with assurance that
}        the Root of Trust elements of the device were verified by the
}        manufacturer before the device was shipped.

I'm not sure if the device is actually identified to the verifier (network admin).
Or that there is a *meta* claim that the device could be identified.

Is this a claim that a claim was made, but the contents of the claim is not
revealed for privacy reasons?  If that is the intent, then can we be more
explicit?  (And that's actually a new use case).
If that's not the intent, then perhaps the passive language that is confusing
could be changed.

>   o  Processor Sleep Modes: Embedded equipment typically does not
>      "sleep", so sleep and hibernate modes are not considered.

why is this a consideration?
lots of embedded systems go into low power mode all the time.

re: 2.4.1: DevID Alternatives.

I don't find the use of LDevID to be a credible solution here.
It seems that LDevID have to get installed manually, via some privacy
preserving mechanism.  Privacy preserving against who?  The person or
entity that installs the LDevID surely gets to learn the identity
of the device.   I don't think we can do zero-touch provisioning
without the IDevID.

I would like this section to clarify the privacy threat here.

>   The TCG TPM 2.0 Keys
>   document [Platform-DevID-TPM-2.0] also outlines procedures for
>   creating Local Attestation Keys and Local Device IDs (LDevIDs) rooted
>   in the manufacturer's IDevID as a check to reduce the chances that
>   counterfeit devices are installed in the network.

[Platform-DevID-TPM-2.0] <-- seems to be a draft, and so probably not public?

>   whether the measured hashes are "the right ones" or not.

up to now, you've carefully said "measurements", rather than measured hashes.
Do you want to stick with measurement, or was there a reason to change?

>   Quotes from a TPM can provide evidence of the state of a device at
>   the time the quote was requested, but to make sense of the quote in
>   most cases an event log of what software modules contributed which
>   values to the quote during startup must also be provided.  The log

As I understand it, the problem of the multi-process (and multi-processor)
boot is that the hash values arrive in non-deterministic orders, and so
would contribute to a straight sequential hash differently.
Why aren't the different contributions either just listed, or just filled
into a table with a canonical order?   I'm sure you have thought of this,
so there must be something I don't understand about why this solution
can't work.

If one expects ten processes, A->J to be running, have a table that
is ten items long.  If one needs to be sure that there are no other processes
running, then some measurement of a canonicalized process table seems to
be in order. That would omit the PID for instance, or canonicalize the
PID into some abstract namespace if relationships between processes were also
important.

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

---

From: Guy Fedorkow <[email-masked]>
Date: Tue, 10 Sep 2019 12:45:31 +0000

Michael,
  Thanks for reviewing the doc!
  I'll go over the comments with Jessica and start on a revision.
/guy

Juniper Business Use Only

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, September 10, 2019 7:05 AM
To: [email-masked]
Subject: [Rats] regarding rats-network-device-attestation

I have read through this document, and it is now the publically available reference on the TCG work for the use-case document.  I have sent some edits directly to the authors.

I like the use of the term "Remote Integrity Verification".
I'm not too crazy about "RIV" as a TLA in a field with way too many TLAs already though, but okay.

Is this a claim that a claim was made, but the contents of the claim is not revealed for privacy reasons?  If that is the intent, then can we be more explicit?  (And that's actually a new use case).
If that's not the intent, then perhaps the passive language that is confusing could be changed.

I don't find the use of LDevID to be a credible solution here.
It seems that LDevID have to get installed manually, via some privacy preserving mechanism.  Privacy preserving against who?  The person or entity that installs the LDevID surely gets to learn the identity
of the device.   I don't think we can do zero-touch provisioning
without the IDevID.

>   values to the quote during startup must also be provided.  The log

As I understand it, the problem of the multi-process (and multi-processor) boot is that the hash values arrive in non-deterministic orders, and so would contribute to a straight sequential hash differently.
Why aren't the different contributions either just listed, or just filled
into a table with a canonical order?   I'm sure you have thought of this,
so there must be something I don't understand about why this solution can't work.

If one expects ten processes, A->J to be running, have a table that is ten items long.  If one needs to be sure that there are no other processes running, then some measurement of a canonicalized process table seems to be in order. That would omit the PID for instance, or canonicalize the PID into some abstract namespace if relationships between processes were also important.

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