On 20.11.2015, at 16.47, Kathleen Moriarty <[email protected]>
wrote:
>> 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?
The MUST MTU here is only for (relatively small) subset of U cases. Therefore,
if a product (or a network) does not see those cases happening, broad MTI/MTU
causes extra bloat without any benefit (like my home network case I mentioned).
For example, given Markus’ Home Network product does not support insecure
(L2-wise) network, having MTI DTLS/TLS causes bloat and solves nothing and
makes product harder to ship.
> I think my question on what is "secure mode" and request for a
> reference is still outstanding.
Ah, sorry, simply too much mail backlog. ’secure mode’ in that context should
be probably just secure _transport_ enabled on that particular link/for a
particular remote endpoint, that is, the {TLS,DTLS} based one described in the
rest of the text.
I wonder if we should edit dncp too, I don’t think that term appears anywhere
elsewhere in the document.
Cheers,
-Markus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet