[secdir] secdir review of draft-ietf-alto-protocol
"Dan Harkins" <dharkins@lounge.org> Sat, 01 February 2014 18:54 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877D71A05ED; Sat, 1 Feb 2014 10:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
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 Kpb7ARPbBtDy; Sat, 1 Feb 2014 10:54:09 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5F1A05CF; Sat, 1 Feb 2014 10:54:09 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CFBF31022400A; Sat, 1 Feb 2014 10:54:05 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 1 Feb 2014 10:54:05 -0800 (PST)
Message-ID: <cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net>
Date: Sat, 01 Feb 2014 10:54:05 -0800
From: Dan Harkins <dharkins@lounge.org>
To: draft-ietf-alto-protocol.all@tools.ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-alto-protocol
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 01 Feb 2014 18:54:11 -0000
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. This draft defines a protocol that allows a server to provide network location information, network structure and network cost/preference to a client which then can build an abstract view of the network in order to determine how best to use it. This draft is "ready with nits" (per secdir review instructions). And those nits are: - 6.1.1.1 mixes the idea of "cost" and "preference". While it's natural for people to prefer lower cost I think it would be better to say so explicitly: "A lower value indicates a lower cost" or this field "conveys a generic measure indicating preference for routing traffic from source to destination" or something like that. - 6.1.2, while a particular Cost Map may contain only one of the two cost modes, servers MUST implement support for both, right? It's not clear from the text. - 6.3, since the tag must not contain ASCII characters below 0x21 or above 0x7e you can't really construct one from the hash of the contents of a Network Map. Also, given those restrictions and the fact that a tag just has to be less than or equal to 64 octets, the probability of identical tags being used is not zero. I think the probability of the tag from example 11.3.1.7 is 0.5 to collide with one of just 460 other Network Maps. I suggest requiring a tag to be 64 octets. That will make even money probability of collision among nearly 3000 other Network Maps, which is safer. - 8.3.5, encryption and integrity protection go hand-in-hand, they cannot be "and/or". Suggest changing the sentence to "When confidentiality and data integrity between client and server are required, and server and/or client authentication is required ." This section should refer to section 15 (Security Considerations). - 11.3.2.6, what does it mean for a Version Tag to be "consistent with" another Version Tag? Do you mean that they are "identical"? Same length and same value? Or would "0004579342" be "consistent" with "4579342"? - 15.3.1, the ALTO data can be sensitive since it includes things like endpoint addresses (useful for those who like to monitor the Internet). I think risk (2) here should include mention of that. There may be classes of ALTO data for which certain clients are authorized to receive and others are not. - 15.3.2, the Security Considerations section seems an odd place for normative language-- "HTTP Digest authentication MUST be supported". I suggest finding a more appropriate place, perhaps 8.3.5, to spell out normative requirements. Also, authenticating the client in the TLS exchange would be much preferable and I think mention should be made on that option. I think differentiated authorization (see my previous comment) would be easier this way too. - 15.4.2, authorization of an authenticated client is another useful protection strategy here-- some client's may get obfuscated data, and some may get the raw data. I think the Security Considerations are well done. regards, Dan.
- [secdir] secdir review of draft-ietf-alto-protocol Dan Harkins
- Re: [secdir] secdir review of draft-ietf-alto-pro… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-ietf-alto-pro… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-alto-pro… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-alto-pro… Richard Alimi
- Re: [secdir] secdir review of draft-ietf-alto-pro… Richard Alimi
- Re: [secdir] secdir review of draft-ietf-alto-pro… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-alto-pro… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-alto-pro… Richard Alimi
- Re: [secdir] secdir review of draft-ietf-alto-pro… Richard Alimi
- Re: [secdir] secdir review of draft-ietf-alto-pro… Y. Richard Yang
- Re: [secdir] secdir review of draft-ietf-alto-pro… Dan Harkins
- Re: [secdir] secdir review of draft-ietf-alto-pro… Dan Harkins