Re: [secdir] review of draft-richer-vectors-of-trust-11

Justin Richer <jricher@mit.edu> Fri, 22 June 2018 18:11 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318A6130EBB; Fri, 22 Jun 2018 11:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 qbLsMt-utc6B; Fri, 22 Jun 2018 11:11:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E75E130E10; Fri, 22 Jun 2018 11:11:56 -0700 (PDT)
X-AuditID: 1209190d-445ff7000000194d-4b-5b2d3bea693e
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 7B.6B.06477.AEB3D2B5; Fri, 22 Jun 2018 14:11:54 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w5MIBrcC028963; Fri, 22 Jun 2018 14:11:53 -0400
Received: from [192.168.1.4] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5MIBoDQ027147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2018 14:11:51 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net>
Date: Fri, 22 Jun 2018 14:11:49 -0400
Cc: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9AA1FE3-F574-4F92-B06F-04269D26C5DD@mit.edu>
References: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net>
To: Klaas Wierenga <klaas@wierenga.net>
X-Mailer: Apple Mail (2.3445.8.2)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrPvKWjfaoOWOlcX2DyvYLGb8mchs MfPiJWaLDwsfsjiweCxZ8pPJY/K774wBTFFcNimpOZllqUX6dglcGVembmMuOKRdse7HGtYG xh9KXYycHBICJhKNk1axdzFycQgJLGaS6H3yjRHC2cgoMfHuMWaQKiGBa0wSnzezgtjMApoS +7uXs3QxcnDwChhLrL9YDhIWFjCXONa4ixHEZhNQlZi+poUJpIRTwEHiUbc3SJgFKHz/w2U2 iCl+Elt7f0LZ2hLLFr4G28QrYCUxcWUXK8RWe4lZX1vARooIqEt833mYHeJmRYlFGxtYJzAK zEJy0CyEg2YhmbqAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGcNhK8u5g /HfX6xCjAAejEg+vxledaCHWxLLiytxDjJIcTEqivDcrgEJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeN2eAuV4UxIrq1KL8mFS0hwsSuK82YsYo4UE0hNLUrNTUwtSi2CyMhwcShK8/610o4UE i1LTUyvSMnNKENJMHJwgw3mAht8GqeEtLkjMLc5Mh8ifYtTlOHZ5Wg+zEEtefl6qlDjvV5Ai AZCijNI8uDmgdOO+zs7iFaM40FvCvIzA5CPEA0xVcJNeAS1hAlpS3awFsqQkESEl1cDYFXFi VqO2QkrnNZ+VdxTCfn84pSQeEa3q9iDkubzOU8avYsZlN/vXL935oWSr19+IW9dlbuTlMsj9 ErIoLzA4yx+0KXFehem79A2+F3WlM5bW1+mpTtuqcMVWr31SfTfX1FmmgUv3VzSH6Saob1XZ kM9StprlwcVfU81vzdvxXP6AV+/jjIlKLMUZiYZazEXFiQDAHnn3EgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/5L5F_uyayw7KR2tWwLC8QRYR5wg>
Subject: Re: [secdir] review of draft-richer-vectors-of-trust-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2018 18:11:58 -0000

Hi Klaas, thanks for the review. I’ve replied inline and have addressed your comments in the working copy where applicable. 

> On Jun 19, 2018, at 10:46 AM, Klaas Wierenga <klaas@wierenga.net> wrote:
> 
> Hi,
> 
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the  IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
> 
> The summary of the review is: "ready with nits"
> 
> The document defines a method of signaling multiple relevant aspects of a digital identity transaction instead of a single "level of assurance" that is supposed to capture all of those aspects into one single value.
> The document is well written and provides clear guidance as to how the various aspects of an identity transaction can be expressed, without exploding the solution space. The majority of the comments I have are to do with assuming too much prior knowledge from the reader and two more subtsntial comments:
> 
> 
> chapter 1, page 3: the second paragraph describes the vectors rather abstract which may prove difficult to the reader, I would recommend to add here something like "for example identity proofing, credential strength etc.) instead of in the 4th paragraph

The paragraph prior to the one mentioned here has just such an aside, and repeating it in the next paragraph would be redundant in my opinion. 

> 
> chapter 1.1: I thought some of that terminology had been defined in another RFC, but unfortunately I couldn't find it

Most of these are terms of industry but if there’s a specific external reference that we can include informatively I’d be happy to add it

> 
> chapter 1.2: The main thing I am missing here is a reference to Attribute Authorities (AAs). I do realise that introducing AAs complicates the trust model big time, and am totally ok with declaring that out of scope, but I don't think you can just pretend they don;t exist, especially since we are seeing a movement towards it.

I really don’t want to go into that depth — as stated in the intro, we are trying to avoid the complexities of all-attribute-all-the-time systems. We distinctly do not want to get into attribute metadata here, which is where the attribute authority model really starts to come into play. 

> 
> chapter 2.2: I am not crazy about the word "Usage", I think you are looking for a word that expresses something akin to "strength" (without wanting to imply ordering)

We originally started with “strength” but that implies more than we wanted it to in terms of one being “better” than the other. The real bit is “what does the person need to do in order to make the credential do its thing with the server they’re trying to authenticate to” but that’s a bit long. :) In the end, we felt this category captured “how do you use this credential” and went with “usage” in order to stay neutral.

> 
> chapter 2.2, paragraph 2: You write that no ordering should be implied, and I presume that is why you distinguish between vectors that use numbers and those that use letters. I find that not very convincing, letters equally imply order, so i see no compelling reason to not use either numbers or letters in all cases instead of mixing up

This is a good point, and I’ll try to make the wording here clearer. You can of course assign letters to things with natural ordering, but it also often makes sense to not necessarily use the letters as an ordered list. In the NIST implementation, for example, “Pi” means “in person”, “Pr” means “remote”, “Pt” means “trusted referee”, etc. 

> 
> chapter 3.2: have you considered adding also a SAML example, since that is widely used as well?

As Ben mentioned, yes, and it’s gone now. I’d be happy for someone to make a SAML binding to VoT but at this point I think it would make more sense in another document. 

> 
> chapter 8.1: it is unclear to me what meeting the criteria means (and what is good, what is bad, and what the treshold should be)

The intent is in the guidance to the DEs in the second paragraph: 

 - It shouldn’t be a duplicate of something that’s already out there
 - It should be clear whether it’s of general applicability or something very case-specific (and if it can be the former, that’s preferred)
 - The definition of the category should be clear enough for a trust framework to define values for it and for people to use those values

If you have suggested text for making that set clearer I’m happy to incorporate it.

> 
> chapter 9: isn't it true that the "strength" of the assertion of a vector can only be as good as the cryptographical protection in transit?

That’s one limiting factor, but there are others including the amount of trust that can be put in the IdP making the assertion in the first place. 

> 
> Cheers,
> 
> Klaas
> 

Thank you,

 — Justin