Re: [Rats] Use case -> architecture document

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 10 October 2019 14:43 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 F1FCC120108 for <rats@ietfa.amsl.com>; Thu, 10 Oct 2019 07:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 SyTd7F_7JC5Q for <rats@ietfa.amsl.com>; Thu, 10 Oct 2019 07:43:38 -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 613E51200E7 for <rats@ietf.org>; Thu, 10 Oct 2019 07:43:38 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id 89so5062343oth.13 for <rats@ietf.org>; Thu, 10 Oct 2019 07:43:38 -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=VSHapx3E5INvSBVkpurndNQqD3ay+iHvm8YtQhDN4QM=; b=c/lclL+rhk9Hy+TSFkSr3XEKjWbJSFjwnpuyr1Z7a4QUaFU77uOaKRbbGWdjZWZYSB 8x42USv2oUoSeFPg5/6+tQWLkyJp6hfe0+oVV1VsF+u9v0F5TkbJ9IHH0SFqS/cqDuBn lwhBSPbvE0bB353MvGeYSwVEDRGCzsNO9Cp3tJmkGD5MDDMB+GtZkYMa6B6EZ9Ql/Xwz nqAm8OQ6stGEVBifj9JK+2Xf4PqZ7fcAd7M1m1Qpyn9Oc34fzSNQOiHU6CEP5I7ingJz REsjUwfE3n3EmyC5SctPqdxoQjLxNN9o/8CeFnHTBkUBLYD6eE34+3NstfL9oSTCJ6LA 8OIQ==
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=VSHapx3E5INvSBVkpurndNQqD3ay+iHvm8YtQhDN4QM=; b=sos2xNyLVsTnc6FDm6OPEOYOG2XIG91xsckUcLw8teX+q07XU0ttNymAXabaabOvgM Jdw4RwEnUI6fm+uy1JFfxxQ6lH0rtBjzxUugT7E2R6NeIhqP/kJN3ebsUYhNOW9MylVv 6m7C0mHU4kLWX0z2PImpvXCVyOQk3O4ZKAkf85hW79SRd8esi/7+za4jLKtk1ihqyrFf TgdhEFJCu0DOu7VHGjWVDLVgfTskC5CF2x+mB0kpmQMjlseyQzlNTgcveSE/Qd7ylKu9 cJX8yDP20p2t/ZCoNbbSgWmva0p652i3n2XDcnCjupXcXUOlTgoirgLOJnOlou2kUVmC rgrg==
X-Gm-Message-State: APjAAAXMmWageQ2fvmuRqt2xOO2Uj+nEIJnLFl/PMUZMSC2PN2NE9oh4 Ot+X4HXs+/aOwmFNP+htDeN1QR6EWrIyFpoTHpk2GOtp
X-Google-Smtp-Source: APXvYqwJJhi1D4N1XPJ4NiorKkUHS7kMkP35rTuKKzaBeu2BB3twjUyRu06YLZqTDMiXjZa0Xw1R6Nj2J1mBT5zCNgo=
X-Received: by 2002:a9d:4813:: with SMTP id c19mr8151671otf.114.1570718617625; Thu, 10 Oct 2019 07:43:37 -0700 (PDT)
MIME-Version: 1.0
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> <203F8673-A9B0-446B-966B-1FD05A5C2D41@tzi.org>
In-Reply-To: <203F8673-A9B0-446B-966B-1FD05A5C2D41@tzi.org>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 10 Oct 2019 10:43:00 -0400
Message-ID: <CAHbuEH4RQNWh8GHPsi51_gZexKpi5KXagQvTe7tQgemHcqGY7Q@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Juergen Schoenwaelder <J.Schoenwaelder@jacobs-university.de>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003eea1805948f6dd3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/fjMeA8wscnlxCyFwXJBRt4x2_vk>
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: Thu, 10 Oct 2019 14:43:43 -0000

Hi Carsten,

On Thu, Oct 10, 2019 at 7:45 AM Carsten Bormann <cabo@tzi.org> wrote:

> Hi Kathleen,
>
> It is hard to keep up with this torrent, and I’ll respond to a snapshot.
>
> However, I would like to point out that there is a place for specs, and a
> place for books.
> When 6LoWPAN was done (RFC 4919, RFC 4944), we wrote a book, and that is
> definitely a better place to get a thorough introduction.
>

I'm sure that will be helpful in time too, but companies are moving forward
with attestation using proprietary formats now.  I am concerned and would
like this effort to be as successful as possible.  As a former AD, I have
read thousands of drafts, readability can be achieved with the use of
complex terms being defined.  Just to note, even Henk is not happy with
several of the terms defined.  Please don't insinuate that I don't know the
difference between a book and a draft, this is not helpful to advance this
discussion.  My goal is to actually speed this work up and make it easily
adoptable.  There has been excellent work done and interoperability, as
well as adoptability are critical.

Dave Thaler agreed it could be more readable and offered to help.  He has
likely read as many drafts/RFCs, including architecture drafts across
areas.


> The job of the spec is to crystallize consensus, not to serve as a
> textbook.
> Where editorial issues hinder understanding, this can (and should!) be
> fixed in the WG process.
> Restarting the effort comes with the danger of diluting the hard-earned
> consensus.
>

I didn't say the work would be discarded and clarified that yesterday as I
interpret 'merge' differently than Henk and possibly you, maybe others. You
may have missed that in previous threads.

I believe we are at a point where many would like to see what is produced
in short term to figure out how to make the document more readable.  I
would also like to make it as useful as possible for the IESG approval
process.  The ADs must see the document as useful and having just rolled
off as an AD recently, I am familiar with the inner workings and
challenges. Making this as easy as we can for the current AD is most
appreciated.  They are overburdened, so avoiding unnecessary discusses or
abstains is a goal.


> I like the fact that the spec is 10 pages net now.  Adding examples and
> other material may hinder adoption by making people think that the
> architecture is complex.  It is not.  (I made this mistake enough already,
> no need to repeat it here.)
>
> The main point of the architecture is to define the roles in unambiguous
> terms, and the axioms we have about these roles.  Without this, we cannot
> communicate.  If you try buying a house and don’t understand the roles of
> buyer, seller, bank, and notary, you won’t get a good outcome.  The
> architecture document provides this, and adding introductory material is
> only going to help so much (i.e., please do, but in moderation).
>

I think we should let the work progress and see how the document can be
improved instead of continuing to comment here.  Please do watch your
phrasing on list as this message is an insult to me more personally.

Some do agree the document could read better, so I do hope this has an
impact on improving the document and making the technology more easily
adoptable.  I do hope more at the end of this process agree, and if not,
the WG decides in any case.
I think an improved document that's readable and perceived by others
outside of the area of work is important.

>
> So my recommendation would be to adopt this document quickly, and to fix
> any impediments to understanding it.
>

This work has begun.


> Let the flowers bloom and write great documents about use cases (done),
> usage scenarios and workflow patterns.  These can then also make use of the
> agreed terminology, which will tremendously help in understanding them as a
> group.
> But please don’t hold up the progress of the architecture document by
> introducing non-essential surgery.  We need this document, shipped.
>

I think this short break will actually speed things up.  We will also have
the IESG process and my goal is to make that smooth as well.

Best regards,
Kathleen


> Grüße, Carsten
>
>
> > On Oct 9, 2019, at 18:03, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
> >
> >
> > I would rather see the architectural patterns come before the specific
> terminology.  If you look through the slides from Dave's presentation at
> our previous interim meeting, he laid out several architectural patterns
> using the same language that is used in SUIT and TEEP.  It is desirable,
> IMO, to begin with architectural patterns that can be used in necessary use
> cases.  Additional architectural patterns may arise, but we have a nice
> starting point.
> >
> > See:
> https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment
> > It defines the passport, background check, and verifying relying party
> architectural patterns for RATS.
> > It also provides an illustration of how the OTrP model for device state
> can fold into each of those 3 RATS architectural patterns.
> >
> > What Dave is planning to do is to write text describing these
> architectural patterns.  It will likely be in the language similar to
> what's been used in SUIT and TEEP as his slides match the terminology.
> >
> > Attestation has countless use cases, and several known architectural
> patterns to date.  The document would first define these patterns.  Then,
> like SUIT, a high-level description of use cases could be included with
> pointers to other future WG drafts that more fully define the use cases.
> Any additional terminology that is necessary could then be added, but
> keeping in mind that we do not want unnecessary terms.  If we start from
> the models, it will be easier to maintain the scope and set of terms.  The
> terms would come from the current document, but language may be adjusted as
> needed.
> >
> > The specific use case details that map claims could be in a later
> section with the IANA section defining claims for use cases to be added to
> the CWT and JWT registry.
> >
> > I work for Dell and would like to be able to bring this work forward for
> PoCs.  However, our teams (like many others) use pair programming.  This
> means the 2 coders work as a team and in our model, they rotate to a new
> project every 2 weeks.  This helps with innovation and other benefits.  If
> each pairing team has a significant learning curve, a lot of time will be
> wasted and the PoC would not make progress.
> >
> > If the goal for service providers and others is to use this technology
> (as is my goal), we need to make it something that is accessible to many.
> The developers at many organizations will use crypto libraries, but will
> not necessarily be security people.  They will be starting from a point
> where they do not have security specific language nor this very specific
> set of terms that is being defined.  The simpler we can keep it, the better
> to gain wider adoption.
> >
> > I think if we step back and see what Dave does with the document to
> define the architectural patterns, then we can decide how we merge content
> with readability as a goal.
> >
> > Best regards,
> > Kathleen
> >
> > On Wed, Oct 9, 2019 at 10:50 AM Schönwälder, Jürgen <
> J.Schoenwaelder@jacobs-university.de> wrote:
> > Hi,
> >
> > I did also look at the use cases document (I think -04) after going
> > through the architecture document and I must admit that I did not find
> > it too helpful to understand things better. I did not see anything
> > architectural in there either. I guess I will read the teep
> > architecture next and perhaps that helps me to get a better clue.
> >
> > For people like me who are not deep into this technology yet, getting
> > used to the rather specific terminology and concepts is a certainly a
> > learning effort and I think the architecture document was on its way
> > to get terms well defined and sorted out. Some more examples or
> > explanations may help the reader further and I believe this can be
> > achieved.
> >
> > /js
> >
> > On Wed, Oct 09, 2019 at 01:55:57PM +0200, Henk Birkholz wrote:
> > > Hi Kathleen,
> > > hi list,
> > >
> > > it would help everybody, if you could explicitly highlight what the
> exact
> > > issues wrt readability in the current architecture I-D are - always in
> > > comparison with the use-case I-D, if it is doing a better job in that
> part?
> > >
> > > Jürgen provided a good example of what he found confusing as a first
> time
> > > reader - and that was really helpful and is resulting in ongoing work.
> > >
> > > Please mind, not everything is fleshed out in the architecture (e.g.
> the
> > > workflows derived from the use-cases). The plan was to aim for a stable
> > > nucleus, address the issues raised by the list, go through adoption,
> and
> > > finish the document via the issue tracker in a structured process.
> > >
> > > In summary, without an actual understanding why you (or others!) think
> the
> > > document is still hard to read, there is no way of compare readability
> later
> > > on also. It would be really good to get more precise feedback on that.
> > >
> > > Viele Grüße,
> > >
> > > Henk
> > >
> > >
> > >
> > >
> > > On 09.10.19 13:31, Kathleen Moriarty wrote:
> > > > 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
> > > > <mailto: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
> > > >     <mailto:rats-bounces@ietf.org>] *代表 *Kathleen Moriarty
> > > >     *发送时间:*2019年10月8日19:25
> > > >     *收件人:*rats@ietf.org <mailto: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
> > > >
> > > > _______________________________________________
> > > > RATS mailing list
> > > > RATS@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/rats
> > > >
> > >
> > > _______________________________________________
> > > RATS mailing list
> > > RATS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rats
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> >
> >
> > --
> >
> > Best regards,
> > Kathleen
>
>

-- 

Best regards,
Kathleen