[secdir] secdir review of draft-pal-eidr-urn-2016-01
Tom Yu <tlyu@mit.edu> Tue, 05 July 2016 21:05 UTC
Return-Path: <tlyu@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 90C94128E18; Tue, 5 Jul 2016 14:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 B0zL7M7pyODN; Tue, 5 Jul 2016 14:05:43 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 E235F127078; Tue, 5 Jul 2016 14:05:39 -0700 (PDT)
X-AuditID: 12074422-dc7ff70000001e14-17-577c2122ea6f
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 0A.D4.07700.2212C775; Tue, 5 Jul 2016 17:05:38 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u65L5bkW024086; Tue, 5 Jul 2016 17:05:38 -0400
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u65L5aCm003404; Tue, 5 Jul 2016 17:05:37 -0400
From: Tom Yu <tlyu@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-pal-eidr-urn-2016.all@ietf.org
Date: Tue, 05 Jul 2016 17:05:35 -0400
Message-ID: <ldvy45fn6cg.fsf@sarnath.mit.edu>
Lines: 22
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUixG6nrqukWBNucGSJrsX8rb/ZLGb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGU0/tzHWHCBo2Lq5ifMDYzN7F2MnBwSAiYS ZxceYOxi5OIQEmhjkvi+dR4ThLOBUWLl8f/MEM5rRok7X36ygbSwCUhLHL+8iwnEFhHwkDi7 YCMziC0MNOrOuytgY1kEVCWuz3gBVs8roCux/MpNsBoeAU6J3sNTWSHighInZz5hAbGZBbQk bvx7yTSBkWcWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxgkPG RWkH48R/XocYBTgYlXh4JzyvDhdiTSwrrsw9xCjJwaQkysvyDSjEl5SfUpmRWJwRX1Sak1p8 iFGCg1lJhNdftiZciDclsbIqtSgfJiXNwaIkzhsUeSxMSCA9sSQ1OzW1ILUIJivDwaEkwcut ANQoWJSanlqRlplTgpBm4uAEGc4DNFwKpIa3uCAxtzgzHSJ/ilFRSpyXGSQhAJLIKM2D6wXH tBDjvleM4kCvCPOagVTxANMBXPcroMFMQIN/ulSDDC5JREhJNTD6Ge9cYM/24sjB7V+kRVMm 76840ifLVVHHorDp04LGzff0zD9UHeneFSu0dAKLWqFTleyyisM7Hl40j9Ludud/u09KgzFu y0y5S+0r067auoczanFM9XoecfnA0xcxxzSrq1feS0iqn+Kh/Pm24cYwx3weaSOuFB+OMNGV +9lrXWLObi7c91WJpTgj0VCLuag4EQBa7hUXxAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/bB_jg-Ns3kiOODtREr6ib0s3pjM>
Subject: [secdir] secdir review of draft-pal-eidr-urn-2016-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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, 05 Jul 2016 21:05:44 -0000
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. Summary: ready The security considerations section of this document seems reasonable. The following sentence seems unnecessarily specific, but it was also present in RFC 7302 and doesn't seem harmful to retain. "Note, however, that failure to conform to the syntactic and lexical equivalence rules in this specification when using an EIDR Identifier as a criteria for accessing restricted resources can result in granting unauthorized access to these resources." It appears to me that it would require a confluence of multiple serious implementation and/or configuration flaws for the above concerns to be relevant, e.g., a default-allow policy combined with differing lookup procedures for authorization versus content retrieval.