Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

[Markus Stenberg <[e-mail]>]

On 18.11.2015, at 16.56, Ted Lemon <[e-mail]> wrote:
> Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote:
>> HNCP is an amazingly flexible protocol, and one that will hopefully be
>> used well beyond it's original area of application.  Many of the possible
>> applications of HNCP don't require DTLS, either because the network is
>> secured at a lower layer, or because they use a different application
>> layer mechanism.
> Which possible applications of HNCP don't require security?   The problem we have with HNCP is that we have no basis for establishing trust, not that we don’t need security.

Most home networks in my honest opinion. Let us enumerate the threats:

- If the devices communicate using the wires in the home, if you have a breach there, someone can e.g. do nasty things to devices themselves anyway (for example, likelihood of someone doing on-wire tapping of my home ethernet infrastructure is less than someone actually stealing the Mac Pro, servers and other hardware the ethernet is attached to if they get the access) => physical security wins.

- If the devices communicate using wireless in the home, if you have a breach there, someone can e.g. do nasty things to other devices anyway => no wins in securing HNCP.

Securing HNCP will only make the attacks local, not global (in terms of the network). Someone can still spoof e.g. sending RAs on the local link, or do ARP/DHCPv4 in IPv4 land, and after that pretend to be router etc. Only if we have just point-to-point links (e.g. star topologies), with router as first hop for every node, then securing HNCP actually mitigates some threats. In practise I suspect typical homes will have relatively large number of devices in one or few wireless SSIDs and perhaps something on wires, but that does not imply star topology.

If we contrast that to the current full L2 bridges in homes, the situation is simply same; attacks can be mounted on any insecure link in home and it affects the whole home.

While improving the state of the art here would be nice, I do not really see it as a reason to say MUST to an unproven solution (in terms of deployment and adoption).

> The argument against DTLS that I think makes some sense is "we don't know how to key it, and therefore don't know if it will work if/when we figure out security," not "we don't need it."   I actually have a great deal of sympathy for Kathleen’s view here; if we make DTLS MTI, then at least we’ll have an encryption/authentication mechanism when we figure out how we want to do that.

But we will have no implementations that actually do that. I consider that just harmful code bloat until some distant day in the future in which we have feasible bootstrapping scheme AND implementations in place to use it. 

> I think there's a pretty strong case to be made that the security mechanism will require public key cryptography.   If that's the case, then DTLS will work as an encryption/authentication layer.   The fact that the current draft refers to DTLS and makes it mandatory to use when transmitting pre-shared keys means that we’ve already got consensus that DTLS is a necessary option for encryption/authentication.

Possibly. The jury is still out on what is actually deployable. I am very leery of mandating anything without actual deployment experience.

For example, the current open source DTLS implementations that do non-PSK are woefully small in number, and mostly derive from same, huge, and not so good codebase (naming no names to be polite).

There’s another (much more lightweight) scheme on how to (less well, psk-only) secure DNCP stuff that I actually I use in my home; no draft, as I did not want to muddle the waters, but it is essentially few lines of Python[1] as opposed to half million lines of C that certain unnamed SSL/TLS/DTLS implementation. Obviously it cannot be bootstrapped but neither can be the most common type of DTLS - PSK-based.

As the routing protocol choice was left up in the air for homenet, I consider this to be much more thorny issue, and just saying ‘DTLS+$FOO’ seems dangerous. Especially as none of the current solutions seem that appealing (PSK = practically no go in terms of real deployment, consensus = unproven new stuff, perhaps we want in-home CA?).

> That being the case, I actually don't see any argument against making DTLS mandatory to implement.   You didn't give a reason for your opinion that we should not.   If you do have a reason for thinking that DTLS shouldn't be MTI, please state it plainly--your opinion may well be correct, but if we don't know why you have that opinion, we have no way to evaluate it other than to trust you or not, and that's not a good way to do standards work.   If the concern is whether there's a good DTLS implementation that can be used, I don't know how good it is but tinydtls looks like it might work.   It uses a license that is GPL-compatible.

It is question of threats <-> risks  <-> mitigation analysis. Only thing HNCP security really brings is _in case of insecure L2_ _some_ security for routing/psk state. If we assume every other protocol is secured (e.g. SEND, DHCPv6 ’secure mode’) it may be actually worthwhile, but as long as e.g. DHCPv4 is not secure (and it will never be I suspect), the amount of threats you actually take out of the picture by forcing ’securing’ HNCP alone is not really significant.

To sum it up: I recommend still SHOULD MTI, MUST MTU _if and only if_ L2, but at least _my_ home does not _have_ any insecure L2, or at least insecure in a sense that HNCP running there would be my greatest worry.

Cheers,

-Markus

[1] https://github.com/fingon/pysyma/blob/master/pysyma/shsp.py