On Wed, Nov 18, 2015 at 1:39 PM, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> 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 <cy...@openwrt.org> 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 _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
