Hiya, On 17/09/15 16:00, Steven Barth wrote: > 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.
As long as we're flexible with it, it's not a blocker. And as I said I think it's good, but it may need tweaks as we finish the concrete protocol that uses it. All the rest below is fine but sorry I don't have a catchy better name for 8.3 to hand. (And I don't care about the name so much as e.g. considering RFC7250 which may fit better here, as one wouldn't need a CA.) S > > >> - 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
