IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 09 June 2020 16:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D49B3A097A for <rats@ietfa.amsl.com>; Tue, 9 Jun 2020 09:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IztCyLNKzi4r for <rats@ietfa.amsl.com>; Tue, 9 Jun 2020 09:33:49 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390E53A0905 for <rats@ietf.org>; Tue, 9 Jun 2020 09:33:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 04E1C38A35; Tue, 9 Jun 2020 12:31:20 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aRKUhYVBSRvl; Tue, 9 Jun 2020 12:31:18 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F262D38A32; Tue, 9 Jun 2020 12:31:17 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 36F29696; Tue, 9 Jun 2020 12:33:46 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
cc: "rats@ietf.org" <rats@ietf.org>
In-Reply-To: <AM0PR08MB3716EF125B7B1B5ECB71C79DFA820@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <AM0PR08MB3716EF125B7B1B5ECB71C79DFA820@AM0PR08MB3716.eurprd08.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 09 Jun 2020 12:33:46 -0400
Message-ID: <27651.1591720426@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/8tvb2wYm82tFP82pSrz642KYShY>
Subject: Re: [Rats] Use cases in draft-ietf-rats-architecture-04
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 16:33:52 -0000

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 <Hannes.Tschofenig@arm.com> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email