[secdir] secdir review of draft-ietf-homenet-arch-10
Samuel Weiler <weiler@watson.org> Wed, 11 September 2013 02:54 UTC
Return-Path: <weiler@watson.org>
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 0096211E8108; Tue, 10 Sep 2013 19:54:02 -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 4Xux1yuI0yF8; Tue, 10 Sep 2013 19:53:55 -0700 (PDT)
Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id C963421F9F84; Tue, 10 Sep 2013 19:53:55 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 8EDB746B2A; Tue, 10 Sep 2013 22:53:53 -0400 (EDT)
Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.7/8.14.7) with ESMTP id r8B2rrwm027410; Tue, 10 Sep 2013 22:53:53 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.7/8.14.7/Submit) with ESMTP id r8B2rqSC027403; Tue, 10 Sep 2013 22:53:53 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Tue, 10 Sep 2013 22:53:52 -0400
From: Samuel Weiler <weiler@watson.org>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org
Message-ID: <alpine.BSF.2.00.1309051037400.86627@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 11 Sep 2013 03:53:53 +0100 (BST)
Subject: [secdir] secdir review of draft-ietf-homenet-arch-10
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: Wed, 11 Sep 2013 02:54:02 -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. Even though this is an architecture document, I think it deserves some AD attention. First: it seems odd to set an expectation for (near) zero-configuration: It is not practical to expect home users to configure their networks. Thus the assumption of this document is that the homenet is as far as possible self-organising and self-configuring, i.e. it should function without pro-active management by the residential user. and then decline to give any guidance about, arguably, the most important security choice in the document: This document takes no position on [whether 'default allow' or 'default deny'] mode is the default, but assumes the choice for the homenet to use either mode would be available. I found the "Name spaces" section (3.7.3) a bit confusing, in part because it doesn't specifically name DNS at the start of the section, even though the details below clearly point to DNS (IDNA, possible conflicts with dotless TLDs). Perhaps the second paragraph of 3.7.4, explaining that there are some non-DNS alternatives under consideration, should be moved up? Furthermore, there are some particular assertions in both 3.7.3 and 3.7.4 that need to be reconsidered: -- "When DNS is used as the homenet name service, it includes both a resolving service and an authoritative service." Does it necessarily? -- "The name space(s) should be served authoritatively by the homenet..." Why is that necessary? (Indeed, there is text in 3.7.4 that seems to conflict with this.) -- There is a recommendation to support DNSSEC on the authoritative server side (in 3.7.4). Shouldn't there be a similar recommendation on the resolver side?
- [secdir] secdir review of draft-ietf-homenet-arch… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-homenet-… Mark Townsley
- Re: [secdir] secdir review of draft-ietf-homenet-… Ray Bellis
- Re: [secdir] secdir review of draft-ietf-homenet-… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-homenet-… Ted Lemon
- Re: [secdir] secdir review of draft-ietf-homenet-… Ray Bellis
- Re: [secdir] secdir review of draft-ietf-homenet-… Tim Chown