Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

Markus Stenberg <> Fri, 20 November 2015 14:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AC6A31B31AB; Fri, 20 Nov 2015 06:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.179
X-Spam-Level: *
X-Spam-Status: No, score=1.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EMAIL=2.3, SPF_NEUTRAL=0.779] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Nl3X__3EDxx; Fri, 20 Nov 2015 06:58:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C634A1B31AA; Fri, 20 Nov 2015 06:58:52 -0800 (PST)
Received: from poro.lan ( by ( (authenticated as stenma-47) id 5613C7B1013BCE81; Fri, 20 Nov 2015 16:57:09 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Markus Stenberg <>
In-Reply-To: <>
Date: Fri, 20 Nov 2015 16:58:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc:,, Mark Townsley <>, The IESG <>,
Subject: Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2015 14:58:56 -0000

> On 19.11.2015, at 16.21, Stephen Farrell <>; wrote:
> (Sorry for the N-th discuss, I quite like this protocol and
> I'm sure we'll get 'em all cleared soon, but... ;-)
> I'd like to chat about whether or not the DTLS recommendations
> are correct here. To me, the consensus stuff (from section 8.3
> of dncp) is not clearly baked (as I noted in iesg review of
> dncp). The PKI stuff is well known, even if it it is a PITA from
> many points of view. I don't think a SHOULD for the former and
> a MAY for the latter is appropriate now. If the consensus based
> stuff gets deployed and works, then it might be time to say
> what you're now saying, but I don't think we're there yet. (I'd
> be happy to look @ evidence that we are, and to change my
> opinion accordingly.)

Given bootstrapping PKI seems nigh impossible (home CA anyone?), I am not sure I agree with you.  I have done that few of times and do not recommend it to anyone. Of course, I guess at some point some products may make it painless but I am not sure I will live long enough to see that. (Especially so that the control stays still within home, and does not stray to some American ‘cloud server’, cough cough.)

> Please note that I think I like the consensus based scheme, I'm
> just concerned it may not be ready for prime time. I'm also not
> really convinced that all you need to do to get interop for
> that is mention it and refer to dncp. But again, I could be
> wrong and would appreciate being corrected if so.
> In summary, I think you should say "when using DTLS with
> asymmetric keying, then you SHOULD support the PKI-based method
> and MAY support the consensus based method, which is still
> somewhat experimental.”

SHOULD/MAY neither provide really interoperability anyway, so I am mostly interested about MUSTs. Current PSK MUST I find rather sad, as that is clearly _not_ elegantly bootstrappable.

Trust consensus or even given some leap of faith about home CA <> cloudy CA the PKI-based method seem better in that regard. But I have not seen that much in the wild yet (see the ‘unproven’ argument in the other DISCUSS thread).

So given the context (ideally zeroconf, at least littleconf) home network, what would you pick for the PSK / PKI / trust consensus? Apparently SHOULD/MAY for the two later, but is PSK really the MUST here or is it the PKI?

> -Section 9: You should refer to HKDF and not HMAC-SHA256 though
> the reference to RFC 6234 is still right. HMAC-SHA256 itself
> is not a key derivation function, which is what you want here.

Good catch, thanks, staged for -10[1]. Essentially instead of HMAC-SHA256 recommending HMAC-SHA256 based HKDF with the ‘info’ field the protocol being keyed.

> - Please take a look at the secdir review [1] and respond to
> that as it raises one issue not (I think) otherwise mentioned.
> What is the effect (on a home) of one compromised hncp router?
> Perhaps you'll say that's obvious, or perhaps not, but I'm 
> interested in what you do say, in case it's not obvious:-)
>   [1]

It essentially broadens a number of on-link attacks to network-wide ones. Notably you can redirect arbitrary traffic wherever you want (without HNCP, you do RA/DHCPv4 faster than router on the link -> MITM), and DoS of the network instead of on-link nodes. Additionally of course it also provides view of the topology and the services that use TLVs encoded in HNCP node data so that can be used for various nefarious things as well.