Re: [Rats] Use case -> architecture document

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 09 October 2019 11:31 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
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 64D831200C3 for <rats@ietfa.amsl.com>; Wed, 9 Oct 2019 04:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 AP1amPHewmwg for <rats@ietfa.amsl.com>; Wed, 9 Oct 2019 04:31:50 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F36812008B for <rats@ietf.org>; Wed, 9 Oct 2019 04:31:50 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id 60so1418896otu.0 for <rats@ietf.org>; Wed, 09 Oct 2019 04:31:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sgz19LnFbq40Y9rgUPWKtz0dvOTjqP/eTMJFG+zmAZc=; b=WIN+FSck/oaTt3Cpe+kFROTeOCPov+0FgMW5HgHsIPUj1CQsq/GrYZoTTtqPf3kFeE IntUA6Trbsffqgkwy+Yz3G1MT2Rd2H3gpOedppO5TaEUwvFDIDGI09ZPoYQ1hYXpyXip T2dyVpGsIgj4ntjc0gE1zFGsHDB9l2e2tOAw8uwOP0vuJxYc7SbEppzemtfLfU9W3Tnu eW1/+ljiupN2Da+kyVPJBwHV40aAcee+WywJQKQtT0qtGOfTiZVvTAY7UIuKxZOYLpka EB083rANzid18+vXwCbBDHpIIRQYFea1HEvL7fijsM8nsA2h49mtlUDQRqRmZ8Ri//Hc 3X9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sgz19LnFbq40Y9rgUPWKtz0dvOTjqP/eTMJFG+zmAZc=; b=LuA8snbFA2fVMp7YQlxqhCWyxkwEGwjafNLrnvcT7z19CldpKR0wJYJ3uSC4e33c9d V/7gee4nrFVhr5ojJKmeUN9OjYjQUZAEMGHlXvYB4ZGClg4uyhuTLhJOlQtjujmZweAO EDuR+dl+KbwLxxjtt+6nJuP9aTjbAdZiUuzCXLbCzmcv4meY3g3aC5YRQSC5mOybjvaG Vtzt70PEfZRYfKWi++IOvROPZivH6Ur2izykIeu7BxXa5msFo0eF8DX5dij5wxW+sZlK VTrYp8aoX+agk9WsBJGA8x4EF9cIfXCkChua8KYQ821zvaI+V3c6xN1cJMKQ+rOTf0Z6 IcUQ==
X-Gm-Message-State: APjAAAVY2YuakMoobza5CRCyhsREszPHCNIGRwaL5GWyqjPoRj24KIWW 1cAQS6oNGtHM2Mag7KB0LjCr7C/9V2/7W2gKCzo=
X-Google-Smtp-Source: APXvYqyCwKNpZsI9m/79ksDg9/W9HrTOFSTzumqDa3HFH4tAL72qBm/b21TreF04oUS1b6zGGRN9pJq72+sOgsoqXBo=
X-Received: by 2002:a05:6830:1e59:: with SMTP id e25mr2289813otj.342.1570620709848; Wed, 09 Oct 2019 04:31:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 09 Oct 2019 07:31:12 -0400
Message-ID: <CAHbuEH7WkqeyUW3sL5bdw5N25B6O7ZEF0Qkx03fE5c42Sd4M5w@mail.gmail.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
Cc: "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/related; boundary="0000000000007d3482059478a1a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/NNamuTJ7-j8lDHfv9XHD0jsAfmU>
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, 09 Oct 2019 11:31:53 -0000

Hi Frank,

Thank you for voicing your concern.  I think some may hold off until the
updates are provided, but please do voice your opinions.  I agree that this
work is too important and as such, readability is a high priority.  If you
read through the TEEP and SUIT architecture drafts, they are quite easy to
follow and understand.  That is critical for wide spread adoption.  We may
be able to find a balance, but I think this exercise may speed progress as
we have not decided to adopt this draft yet as a working group item.

As it stands, the use case document is not an architecture document, but it
could be shaped as such and I'd really like to see if we can do that in
short order to have a comparison prior to an adoption call.

Best regards,
Kathleen

On Wed, Oct 9, 2019 at 6:53 AM Xialiang (Frank, Network Standard & Patent
Dept) <frank.xialiang@huawei.com> wrote:

> Hi Kathleen,
>
>
>
> I am very concerned with this new direction and I strongly object.
>
>
>
> Current architecture draft goes through a lot discussions and reaches many
> consensus. Right now, it really helps IETF (Teep for example), FIDO, TCG
> and many others. The only issues are on readability, the standards track
> and the completeness (e.g., passport and background check are still
> missing). It is an very good document and correct terminology is very
> important for remote attestation.
>
>
>
> About use cases document, Its goal is just to clarify a sample list of
> scenarios that remote attestation can apply to and then deduce the
> requirements and the following concrete protocol drafts. It is not fit to
> be an architecture.
>
>
>
> The current architecture is too important for telecom and network
> equipment vendors and service providers. I have strong doubts that current
> EAT and OTrPv2 alone is suitable for the (virtualized) network
> infrastructure situation.
>
>
>
> B.R.
>
> Frank
>
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
>
>
> *发件人:* RATS [mailto:rats-bounces@ietf.org] *代表 *Kathleen Moriarty
> *发送时间:* 2019年10月8日 19:25
> *收件人:* rats@ietf.org
> *主题:* [Rats] Use case -> architecture document
>
>
>
> Hello!
>
> I read through the latest version of the ‘use case’ document yesterday and
> found it very easy to read and understand, meaning I think it is written
> well and could be easily understood by many without having to climb up a
> learning curve.
>
>
>
> First, this could be a very useful document to register claims for the use
> cases.
>
> Second, if the workflow for the passport and background check were added
> and put in terms of the open trust protocol v2 from TEEP, we have a fairly
> nice architecture document that’s easy to read and may gain adoption.  The
> workflows cover the various interactions between roles and TEEP has
> actively broken up OTrP in v2 to accommodate using EAT tokens, this
> would help create that link and make it very clear.
>
> The other thing I like about the use case document and think we should
> expand on is the references to other work items.  This makes it an
> architecture document that maps out the full plan of the WG.  One like that
> was extremely well received by all the ADs that don’t like
> informational/helpful documents.
>
> I’m a bit nervous with the terminology being defined and would love to see
> something like this that’s simplified and more easily adoptable.
>
>
>
> I appreciate the work done to improve the architecture document, but I do
> think the structure changes to the use case document as suggested could
> result in an easier to understand (and therefore easier to adopt) document.
>
>
>
> While the architecture document is more readable, I think we can do
> better.  Adoption is important and our timeliness matters a lot for this
> work.  EATs can be used for may use cases with OTrPv2, so let's keep it as
> simple as we can.
>
> Thoughts are appreciated.
>
> Best regards,
> Kathleen--
>
>
>
> Best regards,
>
> Kathleen
>


-- 

Best regards,
Kathleen