Subject: [Rats] Use cases in draft-ietf-rats-architecture-04

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jun 2020 07:12:52 +0000

Hi all,

I also looked at the use cases in the architecture draft and I believe there is room for improvement.

The use case in Section 3.1. "Network Endpoint Assessment". It lists many features that, IMHO, are probably not provided by attestation (see recent discussion on the SUIT mailing list). I would just focus on this aspect " Remote attestation is desired to prevent vulnerable or compromised devices from getting access to the network and potentially harming others." Don't oversell it.  (FWIW I would delete the second paragraph because the use of root of trust is not useful in context of this use case.)

The use case for confidential computing in Section 3.2 with the "Confidential Machine Learning (ML) Model Protection" is fine.
Attestation allows me to trust the hardware so that I can put my code and my data there so that the computation does not leak to others.

The added value of the "Confidential Data Retrieval" scenario is not clear to me. Yes, can you use confidential computing to prevent disclosing data other than machine learning models as well. If that's the idea of this additional scenario then I would suggest to delete Section 3.3 and rename Section 3.2 to "Confidential Computing" and put an "for example" in front of machine learning data. I do, however, think that it makes sense to be specific in the use cases. You could also add a sentence to Section 3.2 and say something like: "This is an example use case for confidential computing." And put a link to the Confidential Computing Consortium website.

Section 3.4.  Critical Infrastructure Control is a bit too generic because it talks about authorized code and users. Attestation does not provide anything about users. Try to be specific about what a device can do with attestation that it cannot do without. Pick an example from a critical infrastructure.

Section 3.5. talks about the TEEP use case and you could mention that attestation aims to ensure that the device has not been rooted, or does not run in an emulated environment to have a specific example of what attestation could provide us.

Section 3.6 "Hardware Watchdog" is something I have not heard about. The concept of a watchdog in embedded systems is well-known but it has a different meaning, see https://en.wikipedia.org/wiki/Watchdog_timer
Is there a reference to an article or something that indeed confirms that "malware that holds a device hostage and does not allow it to reboot to prevent updates to be applied". Reading through the text makes me feel that you made this up. (FWIW we had a researcher proposing such a remote watchdog but it didn't require attestation. It was never implemented and you can immediately see that there are practical challenges...)

Ciao
Hannes

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: Michael Richardson <[email-masked]>
Date: Tue, 09 Jun 2020 12:33:46 -0400

Thank you for your comments.

I believe that documents go from "too little" text, to a point where there is
now "too much" (oversell) text, and the feedback I'm hearing from you, is that we are
now on the too much side.

Hannes Tschofenig <[email-masked]> wrote:
    > Section 3.6 "Hardware Watchdog" is something I have not heard
    > about. The concept of a watchdog in embedded systems is well-known but
    > it has a different meaning, see
    > https://en.wikipedia.org/wiki/Watchdog_timer Is there a reference to an
    > article or something that indeed confirms that "malware that holds a
    > device hostage and does not allow it to reboot to prevent updates to be
    > applied". Reading through the text makes me feel that you made this
    > up. (FWIW we had a researcher proposing such a remote watchdog but it
    > didn't require attestation. It was never implemented and you can
    > immediately see that there are practical challenges...)

This situation comes from the desktop situation.

The machine has upgraded, and as soon as it would reboot, it would be safe,
but the malware keeps clicking "Cancel" on the "reboot now" dialog.
Applications reasonably can and should say, "No, do not reboot now",
but there needs to be a limit, and the use of a watchdog in a
hardware/firmware TPM module can do that.

It is *exactly* as in the embedded case (keep holding the switch down, or I
blow up), but the "reset watchdog" mechanism is no longer just poking some
hardware register, but rather, supplying some Attestation Result to it as to
health of system.

How can we rewrite this to make this clearer for you?

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jun 2020 16:44:06 +0000

Hi Michael

Thanks for the quick response.

Regarding the hardware watchdog I just feel it is a made-up use case. Is this something people actually want to use in practice?
Today's use of hardware watchdogs aim to deal with non-security use cases (mostly dealing with crashing software).

Ciao
Hannes

The machine has upgraded, and as soon as it would reboot, it would be safe, but the malware keeps clicking "Cancel" on the "reboot now" dialog.
Applications reasonably can and should say, "No, do not reboot now", but there needs to be a limit, and the use of a watchdog in a hardware/firmware TPM module can do that.

It is *exactly* as in the embedded case (keep holding the switch down, or I blow up), but the "reset watchdog" mechanism is no longer just poking some hardware register, but rather, supplying some Attestation Result to it as to health of system.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-
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: Michael Richardson <[email-masked]>
Date: Tue, 09 Jun 2020 13:51:24 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > Regarding the hardware watchdog I just feel it is a made-up use
    > case. Is this something people actually want to use in practice?
    > Today's use of hardware watchdogs aim to deal with non-security use
    > cases (mostly dealing with crashing software).

We've heard from Enterprise people that this is important.
It's not a constrained case.