On Fri, Nov 20, 2015 at 9:21 AM, Markus Stenberg <[email protected]> wrote: > On 18.11.2015, at 16.56, Ted Lemon <[email protected]> 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.
If MTI is not a MUST, how can you MUST the MTU? I think my question on what is "secure mode" and request for a reference is still outstanding. Thank you, Kathleen > > Cheers, > > -Markus > > [1] https://github.com/fingon/pysyma/blob/master/pysyma/shsp.py -- Best regards, Kathleen _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
