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

Benjamin Kaduk <kaduk@mit.edu> Wed, 20 June 2018 01:17 UTC

Return-Path: <kaduk@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 C2DF9130E09; Tue, 19 Jun 2018 18:17:56 -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 ov_q6e9fccb5; Tue, 19 Jun 2018 18:17:53 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 5DB69130E54; Tue, 19 Jun 2018 18:17:53 -0700 (PDT)
X-AuditID: 12074424-f45ff7000000610d-ea-5b29ab4041db
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id DB.24.24845.04BA92B5; Tue, 19 Jun 2018 21:17:52 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w5K1HoRu008124; Tue, 19 Jun 2018 21:17:51 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5K1HjY7019370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2018 21:17:48 -0400
Date: Tue, 19 Jun 2018 20:17:44 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Klaas Wierenga <klaas@wierenga.net>
Cc: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org
Message-ID: <20180620011744.GI4946@kduck.kaduk.org>
References: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqreuwWjPaYP1uYYvtH1awWcz4M5HZ YubFS8wWHxY+ZHFg8Viy5CeTx+R33xkDmKK4bFJSczLLUov07RK4MhY2TGcs2CJesa3zKXMD 4zOhLkZODgkBE4mJH7YxdjFycQgJLGaSeDZzKwuEs5FR4srjzVDOVSaJBf+nsYK0sAioSkxa 1A1mswmoSDR0X2YGsUUE1CW+7zzMDmIzC/hJbO39yQZiCwuYSxxr3AW0goODV8BYYurSeJCw kIC9xKyvLYwgNq+AoMTJmU9YIFq1JG78e8kEUs4sIC2x/B8HiMkp4CDxqNsbpEJUQFlib98h 9gmMArOQNM9C0jwLoXkBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MoLBl d1HZwdjd432IUYCDUYmHl4FZM1qINbGsuDL3EKMkB5OSKC/XCqAQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEV6GUxrRQrwpiZVVqUX5MClpDhYlcd7cRYzRQgLpiSWp2ampBalFMFkZDg4lCd51 q4CGChalpqdWpGXmlCCkmTg4QYbzAA03BlnMW1yQmFucmQ6RP8Woy3Hs8rQeZiGWvPy8VClx 3sMggwRAijJK8+DmgNKNRPb+mleM4kBvCfO+XQlUxQNMVXCTXgEtYQJasqVKHWRJSSJCSqqB MYJrTfgafvsd7JXCT7oE73Qf2RhsHsjhuE/8zTRFj6T7sTKHWv2vdR5S3nt6s5m1rk7btS2s 50zSjV88bnGb4e3w7MCNh68z0y1qEgT4rt88Vv1qmd+Wxb90areIhF1ZafqtftGco9yXMhf0 uwuIMBvNfH7vx/nshxuSRf237DXe4bZr5c0PH5RYijMSDbWYi4oTAax0NGcSAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/dMG1FqXXWXbZ5P7VemkqsJadr8E>
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: Wed, 20 Jun 2018 01:17:57 -0000

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
>