Re: [secdir] secdir review of draft-ietf-homenet-arch-10

Tim Chown <tjc@ecs.soton.ac.uk> Tue, 05 November 2013 00:49 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 D3CE121F9CA9; Mon, 4 Nov 2013 16:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 l0itb8+VShZH; Mon, 4 Nov 2013 16:49:24 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5E06821E836A; Mon, 4 Nov 2013 16:49:08 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50mTX3006568; Tue, 5 Nov 2013 00:48:29 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA50mTX3006568
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383612510; bh=KOmvMs9pp1p0JR6EauYiHI8qOY8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=mfvPEka8MMrDVQZl+P8YBTRZxAB2sSV2PpDs6Gn+vPRzCCCEj+a1vZA1ywfUolWyS 41Wa67TWcBhlJCvMfTExBMSIolxnuqKr+9qHQVtIbC+wuvDuw7iMkKw6OaGyhjXoxa UiiSCLD8zgijKDRR1VI/8JLcbrQARieuUmIaQO0M=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id pA40mY09596347695s ret-id none; Tue, 05 Nov 2013 00:48:30 +0000
Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:dc36:f9fb:865b:22c5] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50l6Lu007907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 00:47:10 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_79A9B6B9-258E-4174-94B3-A16DC1412250"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <alpine.BSF.2.00.1309051037400.86627@fledge.watson.org>
Date: Tue, 5 Nov 2013 00:47:05 +0000
Message-ID: <EMEW3|3b096842186fdbe0e77d4357e19004a6pA40mY03tjc|ecs.soton.ac.uk|BEAB08F9-AC19-4F1F-A299-34AABB85E857@ecs.soton.ac.uk>
References: <alpine.BSF.2.00.1309051037400.86627@fledge.watson.org> <BEAB08F9-AC19-4F1F-A299-34AABB85E857@ecs.soton.ac.uk>
To: Samuel Weiler <weiler@watson.org>
X-Mailer: Apple Mail (2.1816)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=pA40mY095963476900; tid=pA40mY09596347695s; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: rA50mTX3006568
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-Mailman-Approved-At: Mon, 04 Nov 2013 19:05:47 -0800
Cc: The IESG <iesg@ietf.org>, draft-ietf-homenet-arch.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [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: Tue, 05 Nov 2013 00:50:11 -0000

Hi Samuel,

The diff for the -11 is available here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-11.txt

Comments in line,

On 11 Sep 2013, at 03:53, Samuel Weiler <weiler@watson.org>; wrote:

> 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.

- added text in 3.8.2 (ops/mgmt section) about the default deny/allow setting

> 
> 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:

- moved all of section 3.7.4 above 3.7.3; it seems to flow better this way around?
> 
> -- "When DNS is used as the homenet name service, it includes both a
>   resolving service and an authoritative service."  Does it
>   necessarily?

- inserted "typically" wrt authoritative and resolving services
> 
> -- "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.)

- on authoritative service - the WG consensus is to serve name space(s) from the homenet; this means independent operation can be supported.

> -- 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?

- on DNSSEC, the recommendation is intended to be for both; extra sentence added

Also, the phrase "secondary resolving name service" is clarified to "secondary authoritative name serviceā€  

tim