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

[Klaas Wierenga <[e-mail]>]

Hi Benjamin,

Thanks for the explanation.

Klaas

Sent from my iPhone

> On 20 Jun 2018, at 03:17, Benjamin Kaduk <[e-mail]> 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
>>