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

Kathleen Moriarty <> Thu, 19 November 2015 01:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3474F1B3AB8; Wed, 18 Nov 2015 17:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OkZMABq_AHIp; Wed, 18 Nov 2015 17:44:55 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4ADA11B3A9E; Wed, 18 Nov 2015 17:44:55 -0800 (PST)
Received: by wmvv187 with SMTP id v187so3444161wmv.1; Wed, 18 Nov 2015 17:44:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+q34RMj1y9k5O6FyV3TMV0KvTDhFog4vrvKfwbNfEs=; b=0puA6m9M/CRpmk3UireOCVEb38xLqvzgWlTKyXbQVGbQGTU90TkX1AgOhhirUcRyta MVLiG1TbsrIpazImzYaq3KOvRMFuehg8Ku1j7aEDFa3Fr+F6YkCRLqBUoMgsIju0Gnpa 65YzpqkomZSm9jvhJRFOg/GtcGeJiTccbvX4BT02Fq3Aa4mhdInKY7861ESCUnLKRxn+ aIu9MjDHwH28ARxLuSfjYE8Ac/N8wguBaV4jgmUStlpJ3g9LYN2s3cpbKQZcnhhRTDNC rklS8z53GIuf8EMNkhOvMTc6AHIS4UrUgqXNagSMQClVMgORoHtd2IUyJg6MDUO8+BB6 QYoQ==
MIME-Version: 1.0
X-Received: by with SMTP id t4mr5086817wjy.51.1447897493853; Wed, 18 Nov 2015 17:44:53 -0800 (PST)
Received: by with HTTP; Wed, 18 Nov 2015 17:44:53 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 18 Nov 2015 20:44:53 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: Steven Barth <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>, "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2015 01:44:57 -0000

On Wed, Nov 18, 2015 at 1:39 PM, Kathleen Moriarty
<> wrote:
> Hi Steven,
> Thanks for your response and text suggestions.  Inline.
> Sent from my iPhone
>> On Nov 18, 2015, at 9:20 AM, Steven Barth <> wrote:
>> 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.
> This does help, thank you!
>>> 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.
> This may be okay.  I will have to look at the draft again to see the references for DNCP security and will get back yo you as soon as I can do that.  I've had some day job responsibilities this morning.

I don't see any references for "DNCP secure mode" in this draft.  I
see the term used in

but that is also without reference.  Can you point me to the
definition for "DNCP secure mode"?  This may help, I'm not sure until
I can see the definition and can understand if it addresses the points
or not.

Thank you!

>> 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?
> More later.  Thanks again!
> Kathleen
>>> 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


Best regards,