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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 19 Nov 2015 06:21:37 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-hncp-09: Discuss

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-hncp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I agree with Kathleen's discuss that the implementation
requirements for DTLS need to be clarified, hopefully (from my
POV) to make that MTI but I'll leave that discussion to the
other thread.

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

- 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] https://www.ietf.org/mail-archive/web/secdir/current/msg06098.html

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 16:58:48 +0200

> On 19.11.2015, at 16.21, Stephen Farrell <[email-masked]> wrote:

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

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

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

>   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06098.html

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. 

Cheers,

-Markus

[1] https://github.com/fingon/ietf-drafts/commit/7a140efa2693d9b0138654f5ec71e5888caa6777

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2015 15:13:48 +0000

Hiya,

On 20/11/15 14:58, Markus Stenberg wrote:
>> On 19.11.2015, at 16.21, Stephen Farrell
>> <[email-masked]> 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.)

Hmm. I've also setup many small PKIs and don't agree. I do
think someone could easily make all that quite usable within
the home. I agree that that hasn't happened to date though.
(Maybe being a co-author of rfc5280 I probably find all that
PKI nonsense easier to deal with than most developers;-)

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

As you say, it's sad, but I think it's true. For now - it could
be that your consensus scheme might help there but I just don't
think we can be confident of that now. Whereas we do know that
the PKI thing will work, if someone has gone to the trouble to
setup such a PKI.

Summary: I think when using DTLS for this, support for PSK ought
be a MUST, PKI could be MUST or SHOULD and the consensus thing
probably has to remain as a MAY, since we've not got evidence
that it'd work well enough (yet).

> 
>> -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]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06098.html
> 
> 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.

The above may be worthwhile to add to the security considerations.
No harm to remind folks of such things.

Cheers,
S.

> 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.
> 
> Cheers,
> 
> -Markus
> 
> [1]
> https://github.com/fingon/ietf-drafts/commit/7a140efa2693d9b0138654f5ec71e5888caa6777
>
> 
_______________________________________________
> homenet mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 17:35:27 +0200

<snipping resolved parts/earlier comments>

> PKI nonsense easier to deal with than most developers;-)

Chuckle, I was exaggerating slightly too, but e.g. for my retired mother to deal with (even one set up by me) CA seems rather .. challenging. And that’s the level of configuration skill this solution should work with, if it is to be useful.

> that it’d work well enough (yet).

Very well. I swapped the SHOULD/MAY([1]), as I do not consider having two MUSTs really good, and as PKI stuff really is relatively large, I prefer having the minimal guaranteed interoperable implementation be small.

> No harm to remind folks of such things.

All except traffic redirection were already in 12.2. subsection actually. Added traffic redirection there in [1] (it is not intrisic property of HNCP, but given HNCP carries routing protocol keys and/or it is unsecured, ..)

Cheers,

-Markus

[1] https://github.com/fingon/ietf-drafts/commit/f8275e165802a9c310f0bbde98e42087ecc891b1

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2015 16:32:15 +0000

> [1] https://github.com/fingon/ietf-drafts/commit/f8275e165802a9c310f0bbde98e42087ecc891b1

Great, that's fine to sort my discuss point. I'll clear whenever
that's posted

Thanks,
S.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Nov 2015 14:00:52 -0500

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

The IETF has chartered a group, ANIMA, which might produce something useable.
I don't think that homenet needs to invent something on it's own.

As long as HNCP *CAN* accomodate a one-level deep (no chains of trust) PKI,
then it should be good.  So the security has to be MTI, but MAY configure.

I do agree with Markus' here at present.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 26 Nov 2015 17:49:58 +0100

> Hmm. I've also setup many small PKIs and don't agree. I do think someone
> could easily make all that quite usable within the home.

Have you ever walked a non-specialist through the process?

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Nov 2015 09:03:27 -0800

> Have you ever walked a non-specialist through the process?

I'm not Stephen, and I don't play Stephen on teevee, but anything you 
can do with pre-shared keys, you
can do with with an asymmetric keying approach too. Pre-shared keys are 
pretty high touch form of enrollment,
after all. If you can get away with leap-of-faith kinds of enrollment, 
it is even easier IMO because you don't have
to remember messy and/or lousy keys/passphrases:

New Thingy: "I'm blah and want to enroll! my public key is blah-blah-blah"
Enroller: "Sure!" or "Nah, you look sketchy"

Mike

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Nov 2015 18:16:17 +0100

> Have you ever walked a non-specialist through the process?

I wonder why this could not be fully automatic?

Setup a "press button for first login" system similar to WPS for Wifi
that deploys the certificate.

No need for the user to do something complicated.

Henning

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Nov 2015 19:19:18 +0000

> Have you ever walked a non-specialist through the process?

I have not. But as others said, the key idea would be to make
it as invisible as possible, which is quite doable. And the
tools are there these days (much moreso than even 5-6 years
ago) in pretty much all platforms/languages.

S.