Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

On 09/04/15 09:42, peter van der Stok wrote:
> Hi Stephen,
> 
> thanks for the comments.
> There is one comment that I should like to react to before the others:
> 
>> - 7.3, I do not believe that [I-D.keoh-dice-multicast-security]
>> is necessarily going to proceed via the DICE WG. Depending
>> on it would be fairly high-risk in any case.
>>
> 
> I have the same fear. BUT multicast will be used and having a secure
> protocol is an urgent wish.

That's clear. What's not clear is whether or not there is a way
to meet that wish at the TLS layer. Seems that there may not be
is my guess at the DICE WG current thinking.

> I understand the reasons why the current draft will not make it.
> However, I know that other people are working on better sequels.
> I think this multicast security is important.
> Do you think I should add text to emphasize my opinion and encourage
> sequels to [I-D.keoh-dice-multicast-security] ?

That could be fine, but if you do, please consider that the
solution may need to use security primitives above the
transport layer, e.g. perhaps in CoAP payload.

Cheers,
S.

> 
> Peter
> 
> 
> Stephen Farrell schreef op 2015-04-09 01:34:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-roll-applicability-home-building-09: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>> Please correct me if I'm getting this wrong, I honestly may
>> have forgotten the plan. My understanding was that RPL and RFC
>> 7416 etc. were approved on the basis that you needed to get to
>> specific applications of RPL before you could sensibly specify
>> interoperable security with automated key management (AKM) as
>> is clearly required by BCP107 and as has been discussed
>> between security ADs and the ROLL WG numerous times. This is
>> going back to the 2010 discuss from Tim Polk that I inherited
>> in 2011, hence me being uncertain if I remember the plan for
>> sure;-) In any case it seems to me that this draft also
>> doesn't get us to the point where we have a defined way to do
>> AKM (Again, sigh.) I also have a set of comments on that below
>> that I won't make into specific discuss points (at least until
>> we figure out or re-discover the plan).
>>
>> So, with that context, and with real regrets for sounding like
>> an old and broken record, the discuss point: why is this not
>> the ROLL WG draft where we finally get to specify AKM for RPL?
>> If your answer is that this is just an applicablilty statement
>> then I'll ask why it's going for proposed standard, and when
>> to finally expect the AKM spec for RPL (for this application).
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> - I don't get how there's an IPR disclosure for this, but
>> whatever.
>>
>> - The non-security parts of this were quite a good read.
>>
>> - 4.1.8: 1st sentence makes no sense. It says RPL does X or
>> not-X in order to Y. There is no choice but for RPL to do X or
>> not-X.
>>
>> - 4.1.8 seems to me to imply that link layer security is
>> always needed since there can always be some node that will
>> send an unsecured RPL messsage. If you agree, then I think
>> that should be made more clear. If you disagree, I'd like to
>> understand how.
>>
>> - 4.1.8, I am surprised not to see a recommendation that
>> separate group keys SHOULD be used for different applications
>> in the same bulding network. But that may be too fine grained
>> a recommendation for this document perhaps.
>>
>> - 5.1.2.1, I think it'd be clearer to say Imin should be
>> between 10 and 50 ms. The "10 - 50 ms" notation can be
>> confusing. (Same elsewhere.)
>>
>> - section 7, 3rd para, "can rely on" is sales language, please
>> strike that or s/rely on/depend upon/
>>
>> - section 7, 3rd para, last sentence: this is sales language
>> and should be deleted. Or perhaps s/is/SHOULD be/ would turn
>> it back into a piece of specification language.
>>
>> - 7.1 - this is odd text to see in a proposed standard, but I
>> think it's accurately describing the level of interop to
>> expect in RPL security, so is probably the right thing to say.
>> I'd argue that it'd be even better to bluntly admit/say that
>> there is currently no interoperable automated key management
>> for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
>> my discuss point.)
>>
>> - 7.2, 1st sentence: this is meaningless as I read it - what
>> are you trying to say?
>>
>> - 7.2, when a node is stolen, the chances are that any keys
>> contained in the node are at significant risk of being leaked.
>>
>> - 7.3, I do not believe that [I-D.keoh-dice-multicast-security]
>> is necessarily going to proceed via the DICE WG. Depending
>> on it would be fairly high-risk in any case.
>>
>> - 7.4, last sentence: more sales talk
>>
>> - 7.5, what is this specifying? I don't get it. Does 7416 set
>> out what to implement to get interop? (I didn't think so, but
>> nor does this seem to.)
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>