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

Klaas Wierenga <klaas@wierenga.net> Tue, 19 June 2018 14:46 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 D254F130DCB; Tue, 19 Jun 2018 07:46:21 -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 LgPtoC2L4xi8; Tue, 19 Jun 2018 07:46:19 -0700 (PDT)
Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) (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 B7285130F23; Tue, 19 Jun 2018 07:46:18 -0700 (PDT)
Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing1-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w5JEkFYK009472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 19 Jun 2018 16:46:16 +0200
Received: from [2001:610:9d8:4:d106:bda2:89f0:a6cf] (helo=GEANT-AMS-036-Wierenga-2.local) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <klaas@wierenga.net>) id 1fVHtf-0006EG-Oa; Tue, 19 Jun 2018 16:46:15 +0200
From: Klaas Wierenga <klaas@wierenga.net>
To: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org
Message-ID: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net>
Date: Tue, 19 Jun 2018 16:46:15 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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: 0uW0CKfaU - 5ae5dc831f97 - 20180619 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-HnVLfto3DLyRdmfRPpYO5XaPvg>
Subject: [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: Tue, 19 Jun 2018 14:46:23 -0000

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?

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