Re: [secdir] Secdir review of draft-johansson-loa-registry-04

Leif Johansson <leifj@sunet.se> Tue, 03 April 2012 10:32 UTC

Return-Path: <leifj@sunet.se>
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 A309821F8575; Tue, 3 Apr 2012 03:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBYPX7Et-EJf; Tue, 3 Apr 2012 03:32:24 -0700 (PDT)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9C52121F8570; Tue, 3 Apr 2012 03:32:23 -0700 (PDT)
Received: from [109.105.104.225] (dhcp90.se-tug.nordu.net [109.105.104.225] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q33AWG8m008508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 12:32:19 +0200 (CEST)
Message-ID: <4F7AD1AF.3020004@sunet.se>
Date: Tue, 03 Apr 2012 12:32:15 +0200
From: Leif Johansson <leifj@sunet.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Vincent Roca <vincent.roca@inria.fr>
References: <2BAEF3F1-9FDD-4D45-B03D-57A12CAF515F@inria.fr>
In-Reply-To: <2BAEF3F1-9FDD-4D45-B03D-57A12CAF515F@inria.fr>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: draft-johansson-loa-registry.all@tools.ietf.org, IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-johansson-loa-registry-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 03 Apr 2012 10:32:24 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/03/2012 11:18 AM, Vincent Roca wrote:
> Hello,
> 
> 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.
> 
> I have two comments WRT to section 7:
> 
> 1/ It is said: "An implementor of MUST NOT treat the registry as a
> trust framework or federation [...]"
> 
> As I understand the IANA registry is a record of LOA definitions
> that are part of a trust framework. So that's a different concept,
> I agree. But why is this sentence in the "Security Considerations"
> section? It could be moved to section 3 for instance.

I guess it could.

> 
> 2/ The rest of the sentence is confusing IMHO: "An implementor
> [...] MUST NOT make any assumptions about the properties of any of
> the listed level of assurance URIs or their associated trust 
> frameworks or federations based on their presense in the IANA
> registry."
> 
> Do you mean that the fact an IANA registry exists, by itself, does
> not garranty the trust framework actually provides the expected
> security features (i.e. the IANA registry is merely a definition
> record)?

Yes thats the intent!

> I don't like the term "any assumption". If a LOA tells me I can
> achieve some security level by using it, I'll first **assume** it's
> true and in a second step I'll verify it's indeed the case.
> 

What I want to say is that the fact that the entry exists doesn't
imply any quality of the underlying trust framework.

> 
> Typos and general comments:
> 
> ** section 7: - In the first sentence, something is missing: "An
> implementor of MUST NOT" Of what?
> 

I got this from gen-art too. I'm changing it to ".. of software that
consumes the registry"

> - Later: "...based on their presense in the IANA registry" Don't
> you mean presence (with a "c")?
> 
> 
yup

> ** section 3.1: in the example, it is said: "Defines Level 1 of
> FAF" I didn't understand what FAF stands for. I think you'd better
> avoid using an acronym here.
> 

It was an attempt at humor - FAF is the Foo Assurance Framework.

> ** section 3. There's a missing "." before "This" in: "URI:  A URI
> referencing a Level of Assurance Profile This is the registry
> key."
> 

excellent, thx!

> 
> Regards,
> 
> Vincent

Thanks for a great review!

	Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk960asACgkQ8Jx8FtbMZneMQwCeKEPZXGHTUr5cTuKpLsogOnCh
v38AoKrG9h8+AP1raEuyblLHP7s29GLz
=vwLH
-----END PGP SIGNATURE-----