Re: [Teep] TEEP Architecture Last Call Review

Mingliang Pei <mingliang.pei@broadcom.com> Wed, 19 October 2022 09:11 UTC

Return-Path: <mingliang.pei@broadcom.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DC5C14F731 for <teep@ietfa.amsl.com>; Wed, 19 Oct 2022 02:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.665
X-Spam-Level:
X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsmpX8LPkINx for <teep@ietfa.amsl.com>; Wed, 19 Oct 2022 02:11:42 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238A9C14CE23 for <teep@ietf.org>; Wed, 19 Oct 2022 02:11:36 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id k2so38449466ejr.2 for <teep@ietf.org>; Wed, 19 Oct 2022 02:11:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LcEE7bLLr2Qb3kRgH1MDumo7hsq5lkMHix0GAic3jNQ=; b=BlwAZyiZBMEUXoLXATGJK0PjuYR3g/Kv18KiZhh7ZRlrH/wKifSMYO5yNzodablPZq h9kL/krURbBJGQwk2GfOgOWC8GPW7Qliwi5wsFOlBVIYC+qkL3YQky8xMRyIxbSWPVek t82cL/CEtrDJaMccb1+Oo3uiWqrUHQ53Lu0fo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LcEE7bLLr2Qb3kRgH1MDumo7hsq5lkMHix0GAic3jNQ=; b=v3acmjSDlhfSuyEKekDYz9gjW5HlX39IEYVagvaQ2MGe9czHA3wozBFisMugSqslZv SaUpq+9whnheIfHZ24hHQ+2Ya8fnUsDTIlLVObqUGAUpgmhZB0NgRipdantikkkG0J3m yq/Gr2eZ9iAgMJfIyeIOaNipPcIUTktREC7YZxHoTmUxcQUyXNgz6dNEzZGFRVwn/oHt YmU8FsPI9cUlzfwXmGr2NgUuoU/7872LzdIZoEJufZJjHSga9TrrDQ6U7evBEcvJz1mZ p9ZlV/3haToDL50oUwmf1ztiWjS6xGZMv2wlPz9AczRXvvLxLqqNMqoyNwwUCvu1WuoD RK6g==
X-Gm-Message-State: ACrzQf2+EUawZrYftte7+SY7KrmVgbu6YY+Gh9IJJn74g0UWxfRZn0K3 8twcEafhhLFs9wzowcM+WLQjPfa1i2ErhaKpPruRz/f+AdYwzlx0UFECCgcwxzlKyn+WRedWyVL jR0WWCTNdQnU=
X-Google-Smtp-Source: AMsMyM6KnSh6mq54YW2J9wSeDpUkNT4vaGqBNCoyLwXhRhJk6uvOkwhV0hyx/c/B+Q9jTvg+RrxLciziLhFkS4p0lV4=
X-Received: by 2002:a17:907:2da5:b0:78e:1208:8783 with SMTP id gt37-20020a1709072da500b0078e12088783mr5929149ejc.743.1666170694890; Wed, 19 Oct 2022 02:11:34 -0700 (PDT)
MIME-Version: 1.0
From: Mingliang Pei <mingliang.pei@broadcom.com>
Date: Wed, 19 Oct 2022 02:11:23 -0700
Message-ID: <CABDGos78vUzQG58mP5KvxTqkpdsJrY9zOzkOk0WvmaMc9nOooA@mail.gmail.com>
To: mariainesrobles@googlemail.com
Cc: teep <teep@ietf.org>, teep-chairs@ietf.org, Paul Wouters <paul.wouters@aiven.io>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000006eab4b05eb5f9876"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/RyGNL6RKJbfm3GQmxEO6JFIiKnk>
Subject: Re: [Teep] TEEP Architecture Last Call Review
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2022 09:11:46 -0000

Hi Ines,

Thank you very much for your review
<https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-iotdir-telechat-robles-2022-09-04/>
of our TEEP Architecture draft
<https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/>. We have
created an issue tracker in github for TEEP as #250
<https://github.com/ietf-teep/architecture/issues/250>. Please see below
for our comments and a fix that we have adopted. Please also feel free to
check out the Github issue tracker that has more details about discussions
and fixes.


   -

   Pag 9 - Figure 1: The arrows in the diagram are unidirectional, Are there
   cases where it could be bidirectional: e.g. the communication of the
   Agent with
   the Broker?

Ming: we consider it always unidirectional, and don't find a case where we
need bidirectional support. A TEEP Agent inside TEE doesn't call back and
out to a TEEP Broker inside a REE.

   -

   Having an IoT scenario, in your opinion which type of Classes of
   Constrained
   Devices (Class 0, Class 1, etc. [RFC7228
   <https://datatracker.ietf.org/doc/rfc7228/>]) can participate in the TEE
   as a
   "Device" in Figure 1.

Ming: we authors discussed and consider the following:

There is no clear spec from RFC 7228 to say which classes of IoT devices
may fit. We will not specify it and leave such recommendations to the
adopters. And the TEEP allows any code as long as the capacity fits.


Is this fine with you?

   -

   Page 27: "...In some use cases it may be sufficient to identify only the
   class of the device..." what do you mean with class of device? Perphaps
   would
   be nice to add between brackets some examples.

Ming: good suggestion. We provided an example, and a reference to RATS DAA
as follows:

"In some use cases it may be sufficient to identify
only the class of the device, for example, a DAA Issuer's group public key
ID when the attestation uses DAA, see {{I-D.ietf-rats-daa}}."

Is this fine?

Thank you again for your suggestions and reviews. Best,

Ming

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.