Subject: Re: [6tisch] Minutes, 06 March 2015 interim, 6TiSCH WG

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Mar 2015 17:25:03 +0000

Hello René

·         [07.27] architecture draft last call the draft will be generated
in volumes

*	the new security text in the architecture draft is not final. It
still do not have the consensus from the security team. 

RS>> 
The Section 13 security text was provided for inclusion in the architecture
draft, with unanimous consensus by those on the 6TiSCH security calls.
Please also see the minutes of those calls (which I provided pointers to in
my previous email). So, not sure why this still permeates in the minutes.
<<RS

Judging a consensus is difficult. RFC 7282 gives you an outlook on how it is
done. An unanimous agreement on a call is certainly an indication. But that
is limited to the attendance of the call, which in the recent security calls
for which we have minutes do not represent the full DT or even a quorum of
it. In any fashion, you want to confirm a call on the ML, which I have not
seen happen in the DT ML this time. I think that the text in the minute is
correct and effectively that was said.

*	 
*	needs feedback for that part.
*	will be published on Monday.
*	Rene: Changing 2 words on the section. 

RS>> 
This lacks some context: this refers to suggested disposition of Jonathan
Simon's comments on the architecture draft (according to oral info on phone
call, to the commenters' satisfaction).
<<RS

Added those words in the minute. I also added your proposed update in Archie
06 for the lack of confirmation over the ML. As it goes, it seems that
Jonathan is still not fully happy about sending encrypted data and that
still needs to be resolved.

*	 
*	TW: Can this be resolved in the ML?
*	Rene: complains about the low activity in the ML. 

RS>>
I would not call this complaining, since it is simply a matter of fact. What
about: RS commented that there was low activity level on the ML.
<<RS
Made the change

*	 

*	No proposal submitted by everybody on how to improve PSK problems.

*	Discuss of how the overall architecture of the overall joining
process should be. 
*	According to Rene. There is no technical justification about the
comments made to Rene´s proposal.

RS>> This is not "Rene's proposal": the text in Section 13 was what was
provided by the 6TiSCH Security design team, with unanimous consensus by
those who participated on the 6tisch security calls in January. For feedback
on comments made on Section 13 of the architecture, please see the detailed
technical rationale for disposition (this is not position-based arguing,
simply comment disposition based on technical arguments).
<<RS
Added those words in the minutes.

*	 
*	PT: I was asking to Rene to describe how ISA100 works during a year.

RS>> Not sure what this is all about. Besides, if one really wishes to
criticize, why not do this in private, instead of polluting minutes with
this?
<<RS
This comment was mine. I meant that to my best knowledge, the IETF does not
have access to documents that show that ECC can effectively be used in a
TSCH LLN. I thought that this would have been immensely useful to
demonstrate the feasibility of the approach inn 13.1 with minimal amount of
round trips, and that the DT could have used that model as one of the
sources of inspiration together with Wireless HART. And you, Rene, are the
expert in our team on ISA100.11a security, this is why I asked you long ago
to document it.

*	 
*	TW: the idea of the next IETF meeting is to charter security.
*	Rene: does not support the removal of the section proposed by Rene
in the architecture . 

RS>> Again, the text was proposed by the 6TiSCH security team to Pascal
Thubert for inclusion with the architecture draft. The forelast version was
circulated by Pascal Th to the 6TiSCH mailing list regulars to double check.
All of this suggests that this was not just one person pushing for
something, but something the 6TiSCH security design team wanted to get off
their to-do list.
<<RS
FWIW, I did not suggest removal but move to annex. A consensus on a call is
not sufficient. OTOH, a strong objection on the mailing list may be
sufficient to judge lack of consensus. I have seen mails that I initially
read as strong and valid objections. Now things are settling on smoother
positions. My reading of the review comments is that: 

1)      The issue of clear text vs. join key is not fully agreed upon yet

2)      The text leaves room to options with few round trip but does not say
so. A clear objective to limit the number of round trips would be welcome

3)      In particular, we may decide to treat PSK as a supported method,
which we may not want/need to cover with additional work,  because it is
obvious from the art. But even though, it would still be good to have a
sentence that explains so.

*	[07.??] minimal draft wrap-up

*	Security in minimal: what to say 
*	there will be a network wide network key. 
*	The join process is only for autonomic and scalable network
bootstrapping. 
*	all the nodes have the same key or we have 2 keys? one for the
beacon and one for the data. 
*	how the keys get there is out of scope. 
*	in a network we use 1 key for beacon and another for data 
*	key for data and different key for data. data is authenticated. 
*	 

RS>> I miss some discussion on testing with one key for regular data
protection and using no key in enhanced beacons.
<<RS
Same here. This discussion should now conclude in the main ML, not the
security DT. Anything for the minutes?

*	[07.??] AOB

OTF question about the use of shared cells on reservation. T

*	it seems a confusion with soft cells.
*	move to the ML and at the WG meeting. 
*	No 6tisch call next time. INformal calls to synchronize slides. USe
case prepared for the track case.
*	[08.13] Meeting ends

*	 

 Cheers,

Pascal

_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363