Hi Markus,
On Fri, Nov 20, 2015 at 10:51 AM, Markus Stenberg
<[email protected]> wrote:
>
>> On 20.11.2015, at 17.17, Kathleen Moriarty
>> <[email protected]> wrote:
>>
>> Hi Markus,
>>
>> Thanks for your quick response, inline,
>>
>> On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
>> <[email protected]> wrote:
>>> 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).
>> Can you propose text that clearly describes this for developers and
>> implementors to replace the current text and we'll see where we are
>> at? If it makes enough sense, I may be okay with that. Stephen also
>> supported my discuss, so both of us may need to review and possibly
>> tweak it. The current text isn't clear enough to convey what's been
>> described int his thread.
>
> I am not really a wordsmith, and as I am completely happy with the ’security
> of unicast traffic’ (given the delta in [1]), I am not really sure what is to
> be done about that. Perhaps Steven can come up with something.
>
> The text currently looks as follows:
>
> 12.2. Security of Unicast Traffic
>
> Once the homenet border has been established there are several ways
> to secure HNCP against internal threats like manipulation or
> eavesdropping by compromised devices on a link which is enabled for
> HNCP traffic. If left unsecured, attackers may perform arbitrary
> traffic redirection, eavesdropping, spoofing or denial of service
> attacks on HNCP services such as address assignment or service
> discovery, and the protocols secured using HNCP-derived keys such as
> routing protocols.
>
> Detailed interface categories like "leaf" or "guest" can be used to
> integrate not fully trusted devices to various degrees into the
> homenet by not exposing them to HNCP traffic or by using firewall
> rules to prevent them from reaching homenet-internal resources.
>
> On links where this is not practical and lower layers do not provide
> adequate protection from attackers, DTLS-based secure unicast
> transport MUST be used to secure traffic.
>
> Can you and Stephen come up with requirements on what exactly you want in
> this subsection?
I think this new wording helps a lot. I don't consider WPA adequate,
but if you are stating encryption at other layers that are ok without
listing the specific solutions, then I think we are good. In this
thread, WPA was mentioned and as pointed out by others, it's not
adequate, but WEP2 is a lot better. And by ok - I mean provide the
necessary security properties of confidentiality and integrity that
are not subject to attacks (MiTM, etc.). WPA is not mentioned in the
draft, so we may be ok on this with the updated text. Thanks for the
quick turn-around!
>
>>> 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.
>> OK, then for the text where this shows up in this draft, please do
>> replace it with what is meant exactly.
>>> I wonder if we should edit dncp too, I don’t think that term appears
>>> anywhere elsewhere in the document.
>> Yes, please. Since it isn't defined anywhere, just stating what was
>> intended would be much better.
>
> Staged [1] for both dncp(-13) and hncp(-10) that removes ‘secure mode’
> references. I suspect it is remainder of some much older text where we used
> the term more :) Good catch, thanks.
Excellent, thank you!
Kathleen
>
> Cheers,
>
> -Markus
>
> [1]
> https://github.com/fingon/ietf-drafts/commit/363bd9b02108b4f05c03eaa68181a0f972de8c6c
>
--
Best regards,
Kathleen
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
