Hello Stephen, thanks for your review. Please find some comments below.
Cheers, Steven > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > - 8.3 generally: I think this could be the basis for something > quite good but that'll only become clear really (to me) when I > go over it in a real protocol and not in the abstract. I'd > also speculate that you might end up changing this if it gets > more security review, but again that's hard to get in the > abstract. Basically: be prepared for changes as this is made > concrete Understood, the intention is to potentially have something better suited than PSKs or PKIs for cases like bootstrapping a (mostly) unmanaged home network. We are aware that this is probably a first slab at such an approach and might benefit from a few more eyes and practical experience. In any case, it is not substantial to the document and we would rather remove it if it would become a blocker. > - The write up notes various drafts were input to what became > this one. I assume that none of those had associated IPR that > hasn't trickled through to being noted as applying to this > one? If not, as I expect, that's fine, no response is needed, > I'm just noting this since I didn't see any "replaced by" > entries in the history and it's those that cause IPR to be > transitively visible. We are not aware of any IPR associated with those drafts, at least to my knowledge none was declared in the IETF IPR search. > - section 2 - it's not clear to me why all node identifiers > need to be the same length - some protocols using DNCP could I > guess have variable length identifiers. IPv4 and IPv6 and > Ethernet for example all have different lengths. Well, theoretically this is probably not a hard requirement, however the way we currently define our TLVs a variable length identifier here would require changing the TLVs to include a length field for it in some cases. I do not really see the big benefit of allowing this here so we will probably rather leave it as is. > - 4.2: seems to contradict itself. 1st para says that MC is > not used for anything sensitive, but 2nd-last para of section > says that network state TLVs can be sent "now and then." > (Reason to ask is that (D)TLS won't work if sensitive data is > sent via MC.) We do not consider the Network State TLV to be sensitive, since it is a merely a single hash-value over other hashes and a bit of metadata (see "Hash Tree"). The only reaction to the reception of a Network State TLV is triggering a unicast request to the originator (which whould then be authenticated and encrypted) using (D)TLS. We noted this in the Security Considerations already in the first paragraph and mandate rate-limitation of thereby triggered requests. > - 4.4, 2nd para: what is a "valid" address? A profile might e.g. restrict the transport to link-local scoped addresses or make other similar assumptions. I guess we will add a an example in -10. > - 8.1: do you mean one PSK per network or per pair of nodes? > Better to say. I assume it's the former. Well technically it could be either but in practice I'd think we'd assume it to be the former since latter is a bit impractical. > - 8.3: This is an example of (a fairly complex) use of > opportunistic security (RFC7435). Be good to note that. Staged for -10. > > - 8.3: Calling this "certificate based" is I think a misnomer. > I suspect all the same things could be done with raw public > keys (RFC 7250). Well most of it can, however there is one bit that somehow utilizes certificates: A node MUST be trusted for participating in the DNCP network if and only if the current effective trust verdict for its own certificate or any one in its certificate hierarchy is (Cached or Configured) Trust and none of the certificates in its hierarchy have an effective trust verdict of (Cached or Configured) Distrust In any case it could get a different name, do you have a fitting idea? > - 8.3: please do note that a concrete protocol might need > changes to this distributed algorithm and that this section is > guidance and not to be considered entirely fixed (when > coding). Staged for -10. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
