Re: [Rats] Use case -> architecture document

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 October 2019 12:06 UTC

Return-Path: <mcr@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 72215120908 for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 05:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AoTTZDxiTmO0 for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 05:06:11 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A68612023E for <rats@ietf.org>; Wed, 16 Oct 2019 05:06:11 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:64:42:5650:5f0a:e07a:7e5f]) by relay.sandelman.ca (Postfix) with ESMTPS id 50D2D1F455 for <rats@ietf.org>; Wed, 16 Oct 2019 12:06:10 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id E688EFEE; Wed, 16 Oct 2019 14:07:02 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rats\@ietf.org" <rats@ietf.org>
In-reply-to: <20191015154500.ruv2ie36hsxfb3qq@anna.jacobs.jacobs-university.de>
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com> <CAHbuEH7WkqeyUW3sL5bdw5N25B6O7ZEF0Qkx03fE5c42Sd4M5w@mail.gmail.com> <b91baad2-2fc3-a5e4-6898-e2cddcda300d@sit.fraunhofer.de> <20191009145006.r2pjsoo6jxirah64@anna.jacobs.jacobs-university.de> <CAHbuEH6u-6GsJjK8s0eFQPLeSuGjPMgonhyQkmaeA6Q+rp42kA@mail.gmail.com> <9379d880-2b7e-6657-c547-b37bb7a9e466@sit.fraunhofer.de> <CAHbuEH7XfWgPT+=T-Za9Cw-5GRQj0_+WT3L+Kd4aPp6VvU9jAQ@mail.gmail.com> <MWHPR21MB078499E5D4A2A5E697924EC7A3900@MWHPR21MB0784.namprd21.prod.outlook.com> <20191015154500.ruv2ie36hsxfb3qq@anna.jacobs.jacobs-university.de>
Comments: In-reply-to =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FSch=3DF6nw=3DE4l?= =?us-ascii?Q?der=3D2C=5FJ=3DFCrgen=3F=3D?= <J.Schoenwaelder@jacobs-university.de> message dated "Tue, 15 Oct 2019 15:45:01 -0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 16 Oct 2019 14:07:02 +0200
Message-ID: <18413.1571227622@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/cW8JdUTZB_tYT9yk2M5sj5mNFHI>
Subject: Re: [Rats] Use case -> architecture document
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: Wed, 16 Oct 2019 12:06:13 -0000

Schönwälder, Jürgen wrote:
    > Henk's architecture discusses 'Attestation Principles' that are not in
    > Dave's proposal. I guess the WG needs to decide whether to include them
    > or not. Are these important for understanding or guiding the RATS work?

I think that, to the extent that the architecture document includes
requirements on the technical document must answer, that these principles
need to be made explicit.   They should be numbered as well so that we know
which principle to compromise to maintain another one.

    > I also like to mention that there are research papers where the remote
    > attestation process is described more in the form of a challenge
    > response interaction, where the verifier sends a specific challenge to
    > a device and the device returns a response that is than evaluated by
    > the verifier. An example is "compute a hash over certain memory areas
    > within a certain time limit" and then the device returns the result and

That's an interesting thing to add.
I think that this makes for some interesting additions to use cases.

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