Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

Steven Barth <cyrus@openwrt.org> Wed, 18 November 2015 14:20 UTC

Return-Path: <cyrus@openwrt.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629DF1B2E1B; Wed, 18 Nov 2015 06:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=0.001] autolearn=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 yTTpagKk5_nz; Wed, 18 Nov 2015 06:20:28 -0800 (PST)
Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE261B2E15; Wed, 18 Nov 2015 06:20:28 -0800 (PST)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1Zz3az-0007et-3p with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 18 Nov 2015 15:20:25 +0100
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, The IESG <iesg@ietf.org>
References: <20151117235034.24927.22561.idtracker@ietfa.amsl.com>
From: Steven Barth <cyrus@openwrt.org>
Message-ID: <564C8923.5060705@openwrt.org>
Date: Wed, 18 Nov 2015 15:20:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0
MIME-Version: 1.0
In-Reply-To: <20151117235034.24927.22561.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/d4aY1KxnIY-PhPcGU-i4tgiLVsA>
Cc: homenet-chairs@ietf.org, homenet@ietf.org, mark@townsley.net, draft-ietf-homenet-hncp@ietf.org
Subject: Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2015 14:20:29 -0000

Hello Kathleen,

thanks for the review.

> 1. I'm not clear on one of the bullets in section 3, 
>   o  HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
>       non-cryptographic hash function H(x).
> 
> Is this meant to use a message digest (RFC1321) or a cryptographic hash
> for authentication (RFC2104)?  If it's the former, can you make this more
> clear in the bullet?  If it's the latter, can you update the reference
> and the number of bits to use for truncation is 80 for the minimum.  You
> do explicitly mention HMACs later on for PSKs using SHA256, so maybe the
> reference is correct and the wording should just be a bit more clear?

I have staged this text now:

  HNCP nodes MUST use the leading 64 bits of the <xref
  target="RFC1321">MD5 message digest</xref> as the DNCP hash function
  H(x) used in building the DNCP hash tree.

I hope that makes it more clear, that the hash is only used for
comparison and to detect changes, not as a form of signature or
authentication.


> 2. Can you explain why DTLS is a SHOULD and not a MUST?  The bullet in
> section 3 reads as if this is for use, not implementation.  Is there a
> MUST for implementation (I didn't see one, but maybe I missed that)? 

The basic idea behind the SHOULD is that there may be cases where either
physical security of links (e.g. cables) can be ensured or link-layer
security such as WPA for WiFi is present. In these cases (e.g. some sort
homenet wifi repeater) the DTLS would be redundant.

In the Security Considerations sections we currently have a requirement:

  On links where this is not practical and lower layers do not provide
  adequate protection from attackers, DNCP secure mode MUST be used to
  secure traffic.

which should ensure that devices MUST use HNCP security over both
physically and link-layer-wise unsecured links. I guess this could be
reflected in the DNCP profile section as well if that makes it more clear.

Would that work better or do you have something different in mind?


> 
> Could you add a reference to RFC7525 to help with configuration and
> cipher suite recommendations?  This could be in section 12, security
> considerations.

Staged for next revision.



Cheers,

Steven