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

Klaas Wierenga <klaas@wierenga.net> Thu, 21 June 2018 05:28 UTC

Return-Path: <klaas@wierenga.net>
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 C3F821311E4; Wed, 20 Jun 2018 22:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 I4t48Qtyz1R5; Wed, 20 Jun 2018 22:28:48 -0700 (PDT)
Received: from out65-ams.mf.surf.net (out65-ams.mf.surf.net [145.0.1.65]) (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 950A213103D; Wed, 20 Jun 2018 22:28:48 -0700 (PDT)
Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w5L5SgmM031470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jun 2018 07:28:43 +0200
Received: from [62.140.137.116] (helo=[100.116.155.232]) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <klaas@wierenga.net>) id 1fVs9F-0007B4-Gy; Thu, 21 Jun 2018 07:28:45 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Klaas Wierenga <klaas@wierenga.net>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <20180620011744.GI4946@kduck.kaduk.org>
Date: Thu, 21 Jun 2018 07:28:44 +0200
Cc: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <88D1F2CB-0FC2-45A9-BDE7-A21F8D01FE0D@wierenga.net>
References: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net> <20180620011744.GI4946@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Antivirus: no malware found
X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0bW1hsHhO - 7490cfe3a6dc - 20180621 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/q9f6XryN9LKnNCi8j1EFNERnCNg>
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: Thu, 21 Jun 2018 05:28:51 -0000

Hi Benjamin,

Thanks for the explanation.

Klaas

Sent from my iPhone

> On 20 Jun 2018, at 03:17, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> Hi Klaas,
> 
> Thanks for the review!  I am sure the authors will respond, so I
> will just touch on one note...
> 
>> On Tue, Jun 19, 2018 at 04:46:15PM +0200, Klaas Wierenga 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
>> 
>> chapter 1.1: I thought some of that terminology had been defined in another RFC, but unfortunately I couldn't find 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.
>> 
>> 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)
>> 
>> 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
>> 
>> chapter 3.2: have you considered adding also a SAML example, since that is widely used as well?
> 
> There was a SAML example in a previous version of the draft, but
> none of us could convince ourselves that we could validate its
> correctness properly, so we removed it out of expediency.
> 
> -Benjamin (as responsible AD)
> 
>> 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)
>> 
>> 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?
>> 
>> Cheers,
>> 
>> Klaas
>>