Subject: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 17 Sep 2015 05:49:55 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-dncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/

----------------------------------------------------------------------
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 and if that would be a problem please yell now.  If
you do yell, I'm fine with making this a DISCUSS so we're sure
to resolve it. (I nearly did make this a DISCUSS, as I'm not
sure this is all fully worked out, but I'm ok that we can fix
that later. And you have enough DISCUSS ballots;-)

- 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.

- 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.

- 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.)

- 4.4, 2nd para: what is a "valid" address? 

- 8.1: do you mean one PSK per network or per pair of nodes?
Better to say. I assume it's the former.

- 8.3: This is an example of (a fairly complex) use of
opportunistic security (RFC7435). Be good to note that.

- 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).

- 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).

---

From: Steven Barth <[email-masked]>
Date: Thu, 17 Sep 2015 17:00:52 +0200

Hello Stephen,

thanks for your review.
Please find some comments below.

Cheers,

Steven

> 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.

> entries in the history and it's those that cause IPR to be
We are not aware of any IPR associated with those drafts, at
least to my knowledge none was declared in the IETF IPR search.

> 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.

> (Reason to ask is that (D)TLS won't work if sensitive data is
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.

> 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.

> opportunistic security (RFC7435). Be good to note that.
Staged for -10.

> I suspect all the same things could be done with raw public

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?

> guidance and not to be considered entirely fixed (when

Staged for -10.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Sep 2015 16:14:30 +0100

Hiya,

> 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