Re: [Roll] Security threat analysis for applicability draft

[Michael Richardson <[e-mail]>]

see inline. (no hat. Sorry for 6 week delay in answering)

Peter wrote:
> Thanks for the security threats draft. It certainly provides a large part
> of the text needed in the applicability drafts. However, I am not sure I
> interpreted the text according to your intentions.

> Looking at section 7 in more detail, I tried to establish where the
> applicability draft can be complementary to the text of the security
> draft.

It's a good question.  Not being the author of the original document, I've
tried to make minimal changes to the structure, but perhaps this is no longer
sufficient, and we need to restructure this section...  I admit to being a
bit at my whit's end on this document.

> From section 7.1 I understand that key length, encryption algorithm and key
> life time need to be specified. Unfortunately, much of this is still in
> progress and can change with DICE and ACE recommendations.

I'm not I understand how DICE and ACE relate.
We are primarily talking about security for *RPL*, not for application traffic.

> Complementing section 7.2, link-layer security will probably be used today,
> but in 2 years time?

I can't speculate at what point layer-2 security will prove inadequate for
securing RPL.  I think that it will be sufficient in industrial, metering and
building control systems.  Home control systems are another story in my
opinion.  The biggest risk to only layer-2 security is device compromise.
A monoculture combined with systematic IE6 or Heartbleed-type bugs would be
the biggest risk, I should think.

> Complementing section 7.3. Do I understand that using multiple paths for
> reliability reasons should be mentioned as increasing routing security?

Yes, but we presently have no mechanisms for multi-path.

> Complementing section 7.4. Writing down choices, as already provided by the
> threats draft, will be more realistic than writing down recommendations.

Please, can you explain, ideally in text for the document, what you mean here?

> Complementing section 7.5. Is this the place one should write down physical
> access constraints or recommend to provide filtering edge routers at the
> border of the system?

Yes, I guess that would also belong.

> In conclusion, I am very happy with the threats document and its
> recommendations, but I see little opportunity to improve on it in the
> applicability draft.

I couldn't parse this quite right.
Are you saying you see some small opportunities for improvement, or
are you saying that there are no places for improvement?

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-