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

[Kathleen Moriarty <[e-mail]>]

On Wed, Nov 18, 2015 at 1:39 PM, Kathleen Moriarty
<[e-mail]> 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 <[e-mail]> 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
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/?include_text=1

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!
Kathleen

>>
>> 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,
Kathleen