Subject: [6tisch] (suggested disposition) Re: Last call for draft-ietf-6tisch-architecture-05

From: Rene Struik <[email-masked]>
Date: Thu, 05 Mar 2015 19:26:52 -0500

Hi Jonathan:

Please find below my suggested resolution of your comments related to 
security.

Best regards, Rene

On 2/17/2015 1:49 PM, Jonathan Simon wrote:
> My 2¢ feedback on the security section:
>
> 13 - Sending link-layer frames in the clear in the initial stage of 
> joining is not providing any benefit. We should always use 
> authentication, even if the key is not secret, as it provides the 
> ability to reject similar frames from other 802.15.4-based protocols. 
>  It also isn’t necessary to discuss such a detail here.
RS>>
I would suggest we replace the first sentence of p. 31, 1st para by the 
following one:
"This architecture operates on IEEE802.15.4 and expects link-layer 
security to be enabled at all times between connected devices, except 
for the very first step of the device join process, where a joining 
device may need some initial, unsecured exchanges so as to obtain its 
initial key material."
<<RS
>
> 13.1  -
> * "Triage" - So the JCE decides which nodes are more important and 
> assigns resources to them first? How?  Note this term is not used in 
> draft-richardson-6tisch-security-architecture-02.
> * "arbitrage" should be “arbitrate”
RS>>
I would suggest changing the definition of the JCE (p. 31, logical 
elements enumeration) to the following, to reflect this: "A Join 
Coordination Entity (JCE) that arbitrates network access and hands out 
network parameters (such as keying material);".

This brings it nicely in line with the use of arbitraging on the next 
page (p. 32, 3rd para, third line), where "that arbitrages" is replaced 
by "that arbitrates".
<<RS
>
> Other than that, it seem to be capturing the overall spirit of the 
> security architecture and highlights the open areas of security 
> discussion, e.g. that PANA is an open issue.
>
> Couple minor points:
> -- 
> Jonathan Simon, Ph. D
> Director of Systems Engineering
> Linear Technology, Dust Networks product group
> 32990 Alvarado-Niles Road, Suite 910
> Union City, CA 94587
> (510) 400-2936
> (510) 489-3799 FAX
> [email-masked] <mailto:[email-masked]>
>
> **LINEAR TECHNOLOGY CORPORATION**
> *****Internet Email Confidentiality Notice*****
>  This e-mail transmission, and any documents, files or previous 
> e-mail messages attached to it may contain confidential information 
> that is legally privileged. If you are not the intended recipient, or 
> a person responsible for delivering it to the intended recipient, you 
> are hereby notified that any disclosure, copying, distribution or use 
> of any of the information contained in or attached to this 
> transmission is STRICTLY PROHIBITED. If you have received 
> this transmission in error, please immediately notify me by reply 
> e-mail, or by telephone at (510) 400-2936, and destroy the 
> original transmission and its attachments without reading or saving in 
> any manner. Thank you.
>
> On Feb 12, 2015, at 5:06 AM, Shwetha Bhandari (shwethab) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Hello All,
>>
>> We are down to the last week of this last call, and haven't received 
>> any comments/vote yet.
>> Please review and send in your comments / vote, this last call ends 
>> on 18th Feb.
>>
>> Thanks,
>> Shwetha
>>
>> From: Shwetha bhandari <[email-masked] <mailto:[email-masked]>>
>> Date: Wednesday, January 28, 2015 7:05 PM
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>
>> Subject: [6tisch] Last call for draft-ietf-6tisch-architecture-05
>>
>> Hello All,
>>
>> As discussed at the interim meeting last week, we are continuing a 
>> series of last calls for the drafts that the group produced over the 
>> course of the last 2 years.
>> This call is for the architecture draft 
>> http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05 
>> <http://cp.mcafee.com/d/1jWVIqdEI9IzC76jhOyrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCNPX-SgovW_cnKqemmeLsKCOOeUttBBdDBHFShjlhhsVkffGhBrwqrhdECXYyMCY-ehojd79KVI07eJjWtbVKY01M7ox7npBVvdQKVelb4O-NIjBfXjrzVuXVJOsGm9BO5mUm-waBYTu00CQrInsdwLQzh0qmT9OFoCqnjh05tFcQgmQYYQgeRyq848WXcLbVKBT9OFoCnSdysF_qrsvbTvdKndDCi_Ys-j>. 
>> Since both chairs are co-authors, I will be shepherding this 
>> particular document.
>> The call will last for three weeks ending on 18-Feb-2015 and outcome 
>> of the last call will be discussed at the interim call on Friday 
>> 20-Feb-2015, 7AM pacific; please express support or concerns about 
>> the publication of this work, which is originally aimed at 
>> informational status.
>>
>> Thanks,
>> Shwetha
>> _______________________________________________
>> 6tisch mailing list
>> [email-masked] <mailto:[email-masked]>
>> http://cp.mcafee.com/d/1jWVIp4wUq43qb2r8VxNAQsECXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVIs-_JA67-LP5XCzBBzHTbFIIzK7nppjpVqWtAkRkknel3PWApmU6CQjq9K_8I9LfzAm4PhOrKr9PCJhbcatbVKY01MjlS67OFek7qUVelb4PrAVkIjbAaJMJZ0lbVKY01dEToKUr1vF6y0QJKjBiNcQKCy0aXipEwJFVVEwtH4Qg8hRSpunPtbKjBiNcLIr4Vj-QSU-nK-rsKrcD2a
>
>
>
> _______________________________________________
> 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

---

From: Rene Struik <[email-masked]>
Date: Thu, 05 Mar 2015 20:13:10 -0500

Hi Pascal:

My suggested resolution to my comment was the simplest one: to simply 
delete this 2nd para of Section 13. This would also make Section 13 
(minus the 2nd para) reflect confirmed consensus in the 6TiSCH security 
design team [see also minutes conf call of January 22, 2015: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html]).

I think it is somewhat odd to single out one individual security draft 
in the Appendix and not include others, since it raises questions as to 
what the criteria for inclusion and exclusion of those drafts were. To 
avoid going down this path, I personally would rather not give rise to 
those types of questions and simply delete this.

Best regards, Rene

On 2/24/2015 6:03 AM, Pascal Thubert (pthubert) wrote:
>
> Hello René:
>
> I removed that section, and added an appendix that lists the 6TiSCH 
> personal submissions that may impact the next volumes.
>
> The new text reads as follows
>
> /Appendix A.  Personal submissions relevant to the next volumes /
>
> //
>
> /   This volume only covers a portion of the total work that is needed 
> to /
>
> /   cover the full 6TiSCH architecture.  Missing portions include /
>
> /   Deterministic Networking with Track Forwarding, Dynamic Scheduling, /
>
> /   and Security. /
>
> //
>
> /   [I-D.richardson-6tisch-security-architecture] elaborates on the /
>
> /   potential use of 802.1AR certificates, and some options for the join /
>
> /   process are presented in more details. /
>
> //
>
> /   [I-D.dujovne-6tisch-on-the-fly] discusses the use of the 6top /
>
> /   sublayer [I-D.wang-6tisch-6top-sublayer] to adapt dynamically the /
>
> /   number of cells between a RPL parent and a child to the needs of the /
>
> /   actual traffic. /
>
> The diffs are here:
>
> https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/commits/0e07e721ce096cbd02f93c5cfbf9e58e576ac124?at=master#chg-draft-ietf-6tisch-architecture-06.xml 
>
>
> Cheers,
>
> Pascal
>
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* jeudi 19 février 2015 05:39
> *To:* Géraldine TEXIER; Shwetha Bhandari (shwethab)
> *Cc:* [email-masked]; Pascal Thubert (pthubert)
> *Subject:* Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05
>
> Dear colleagues:
>
> I think the draft document draft-ietf-6tisch-architecture-05 is in 
> relatively good shape.
>
> One note: the second para of Clause 13 seems out of place and should 
> be removed.
>
> Best regards, Rene
>
> On 2/18/2015 11:49 AM, Géraldine TEXIER wrote:
>
>     Dear All,
>
>     I have reviewed the draft draft-ietf-6tisch-architecture-05 and I
>     support its publication
>
>     Best Regards
>
>     Geraldine
>
>     -- 
>
>     Geraldine TEXIER
>
>     Associate Professor
>     IRISA/ Reop Team
>     Institut Mines-Télécom ; TELECOM Bretagne  ;
>     RSM Department
>     2 rue de la Châtaigneraie - CS 17607
>     35576 Cesson Sevigné Cedex- France
>     Tel: +33 299 127 038 - Fax: +33 299 127 030
>
>         *From: *"Shwetha Bhandari (shwethab)" <[email-masked]
>         <mailto:[email-masked]>>
>         *Date: *Thursday, February 12, 2015 at 5:06 AM
>         *To: *"[email-masked] <mailto:[email-masked]>"
>         <[email-masked] <mailto:[email-masked]>>
>         *Subject: *Re: [6tisch] Last call for
>         draft-ietf-6tisch-architecture-05
>
>         Hello All,
>
>         We are down to the last week of this last call, and haven't
>         received any comments/vote yet.
>
>         Please review and send in your comments / vote, this last call
>         ends on 18th Feb.
>
>         Thanks,
>
>         Shwetha
>
>
>
>
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Mar 2015 14:28:35 +0000

Hello René:

My perception is that the problem is not there at all. In fact, I’m inclined
to remove 13.1 completely.

My problem with 13.1 is that it does not reflect the WG consensus but a DT
consensus, and from the comment, I’m not even seeing a real consensus there.

In particular, the only art that we have been able to analyze is PSK, and
there is still no documented proof available to the IETF that we can do
better on TSCH.

My suggestion is midway:

- push 13.1 to annex

- add pointers to other security drafts (including yours and Yoshi’s, do I
miss any?)

- and move the definitions at the beginning of 13.1 in the terminology
draft.

I’ll be asking that question at the call today, and by default will apply by
cutoff time.

What do others think?

Pascal

From: Rene Struik [mailto:[email-masked]] 
Sent: vendredi 6 mars 2015 02:13
To: Pascal Thubert (pthubert); Shwetha Bhandari (shwethab)
Cc: [email-masked]
Subject: (suggested disposition) Re: [6tisch] Last call for
draft-ietf-6tisch-architecture-05

Hi Pascal:

My suggested resolution to my comment was the simplest one: to simply delete
this 2nd para of Section 13. This would also make Section 13 (minus the 2nd
para) reflect confirmed consensus in the 6TiSCH security design team [see
also minutes conf call of January 22, 2015:
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html])
.

I think it is somewhat odd to single out one individual security draft in
the Appendix and not include others, since it raises questions as to what
the criteria for inclusion and exclusion of those drafts were. To avoid
going down this path, I personally would rather not give rise to those types
of questions and simply delete this.

Best regards, Rene

Hello René:

I removed that section, and added an appendix that lists the 6TiSCH personal
submissions that may impact the next volumes.

Appendix A.  Personal submissions relevant to the next volumes  

   This volume only covers a portion of the total work that is needed to  

   cover the full 6TiSCH architecture.  Missing portions include  

   Deterministic Networking with Track Forwarding, Dynamic Scheduling,  

   and Security.  

   [I-D.richardson-6tisch-security-architecture] elaborates on the  

   potential use of 802.1AR certificates, and some options for the join  

   process are presented in more details.  

   [I-D.dujovne-6tisch-on-the-fly] discusses the use of the 6top  

   sublayer [I-D.wang-6tisch-6top-sublayer] to adapt dynamically the  

   number of cells between a RPL parent and a child to the needs of the  

   actual traffic.  

The diffs are here:

https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/commits/0e07e721
ce096cbd02f93c5cfbf9e58e576ac124?at=master#chg-draft-ietf-6tisch-architectur
e-06.xml 

Cheers,

Pascal

From: Rene Struik [mailto:[email-masked]] 
Sent: jeudi 19 février 2015 05:39
To: Géraldine TEXIER; Shwetha Bhandari (shwethab)
Cc: [email-masked]; Pascal Thubert (pthubert)
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Dear colleagues:

One note: the second para of Clause 13 seems out of place and should be
removed.

Best regards, Rene

Dear All, 

I have reviewed the draft draft-ietf-6tisch-architecture-05 and I support
its publication

Best Regards

Geraldine

-- 

Geraldine TEXIER

Associate Professor
IRISA/ Reop Team

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thursday, February 12, 2015 at 5:06 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

We are down to the last week of this last call, and haven't received any
comments/vote yet. 

Please review and send in your comments / vote, this last call ends on 18th
Feb.

Thanks,

Shwetha

---

From: Rene Struik <[email-masked]>
Date: Fri, 06 Mar 2015 09:41:59 -0500

Hi Pascal:

I strongly object to this: there was wide consensus on the 6TiSCH 
security calls (please have another read of the minutes). I know you 
have not been on most of the 6tisch security calls, but Thomas Watteyne, 
the other co-Chair has been, who could confirm this.

I think your statement on "In particular, the only art that we have been 
able to analyze is PSK, and there is still no documented proof available 
to the IETF that we can do better on TSCH" is entirely incorrect and not 
based on fact at all.

Best regards, Rene

On 3/6/2015 9:28 AM, Pascal Thubert (pthubert) wrote:
>
> Hello René:
>
> My perception is that the problem is not there at all. In fact, I’m 
> inclined to remove 13.1 completely.
>
> My problem with 13.1 is that it does not reflect the WG consensus but 
> a DT consensus, and from the comment, I’m not even seeing a real 
> consensus there.
>
> In particular, the only art that we have been able to analyze is PSK, 
> and there is still no documented proof available to the IETF that we 
> can do better on TSCH.
>
> My suggestion is midway:
>
> - push 13.1 to annex
>
> - add pointers to other security drafts (including yours and Yoshi’s, 
> do I miss any?)
>
> I’ll be asking that question at the call today, and by default will 
> apply by cutoff time.
>
> What do others think?
>
> Pascal
>
> *Sent:* vendredi 6 mars 2015 02:13
> *To:* Pascal Thubert (pthubert); Shwetha Bhandari (shwethab)
> *Cc:* [email-masked]
> *Subject:* (suggested disposition) Re: [6tisch] Last call for 
> (minus the 2nd para) reflect confirmed consensus in the 6TiSCH 
> security design team [see also minutes conf call of January 22, 2015: 
> in the Appendix and not include others, since it raises questions as 
> to what the criteria for inclusion and exclusion of those drafts were. 
> To avoid going down this path, I personally would rather not give rise 
> to those types of questions and simply delete this.
>
> Best regards, Rene
>
>     I removed that section, and added an appendix that lists the
>     6TiSCH personal submissions that may impact the next volumes.
>
>     /   This volume only covers a portion of the total work that is
>     needed to /
>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Pascal Thubert
>     (pthubert)
>     One note: the second para of Clause 13 seems out of place and
>     should be removed.
>
>     Best regards, Rene
>
>         I have reviewed the draft draft-ietf-6tisch-architecture-05
>         and I support its publication
>
>         Best Regards
>
>         Geraldine
>
>         -- 
>
>         Geraldine TEXIER
>
>         Associate Professor
>         IRISA/ Reop Team
>             We are down to the last week of this last call, and
>             haven't received any comments/vote yet.
>
>             Please review and send in your comments / vote, this last
>             call ends on 18th Feb.
>
>             Thanks,
>
>             Shwetha
>
>
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Mar 2015 09:52:13 -0500

On Mar 6, 2015, at 9:41 AM, Rene Struik <[email-masked]> wrote:
> I strongly object to this: there was wide consensus on the 6TiSCH security calls (please have another read of the minutes). I know you have not been on most of the 6tisch security calls, but Thomas Watteyne, the other co-Chair has been, who could confirm this.

Consensus on a design team call is not working group consensus.   Once the design team knows what they want to say, they have to say it to the working group and try to get consensus there.   So in this context there is nothing to which to object: it is your job now to listen to what the working group has to say and make whatever arguments need to be made to the working group as a whole.   It is entirely appropriate for the working group to overrule the design team in the process of getting to consensus, and you should make your arguments with that in mind.

To go a bit further, just to be as clear as possible, general assent on an interm virtual meeting call is not working group consensus.   Working group consensus happens on the mailing list.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Mar 2015 14:52:32 +0000

Hello René:

My problem number one is that the architecture reflects the 6TISCH
consensus, not your reading of the consensus at the calls that you have
organized, however great the work that is achieved there. We really exposed
the 6TiSCH group too late to that text. I think that the security work
really belongs to the next volutme of the architecture, after we have
rechartered and agreed upon what we will cover.

Second is that Jonathan’s comments really indicate to me that the text is
not even consensus within the group that the chairs named as DT. On the
side, the architecture should not only exemplify certificate based. It must
be made very clear that the art has a lot if not all of PSK.

Third, about 
> I think your statement on "In particular, the only art that we have been
able to analyze is PSK, and there is still no documented proof available to
the IETF that we can do better on TSCH" is entirely incorrect and not based
on fact at all.

This is utterly unhelpful. What would be helpful is that you indicate the
proof that we can use to demonstrate that the text in section 13.1 is
actually workable; such reference would be a valuable addition to the text.
Even though, I’d move the text to annex.

Cheers,

Pascal

From: Rene Struik [mailto:[email-masked]] 
Sent: vendredi 6 mars 2015 15:42
To: Pascal Thubert (pthubert); Shwetha Bhandari (shwethab); Thomas Watteyne
Cc: [email-masked]
Subject: Re: [6tisch] (suggested disposition) Re: Last call for
draft-ietf-6tisch-architecture-05

Hi Pascal:

I strongly object to this: there was wide consensus on the 6TiSCH security
calls (please have another read of the minutes). I know you have not been on
most of the 6tisch security calls, but Thomas Watteyne, the other co-Chair
has been, who could confirm this.

I think your statement on "In particular, the only art that we have been
able to analyze is PSK, and there is still no documented proof available to
the IETF that we can do better on TSCH" is entirely incorrect and not based
on fact at all.

Best regards, Rene

Hello René:

My suggestion is midway:

- push 13.1 to annex

What do others think?

Pascal

Hi Pascal:

Best regards, Rene

Hello René:

   and Security.  

   actual traffic.  

The diffs are here:

 

Cheers,

Pascal

Dear colleagues:

Best regards, Rene

Dear All, 

Best Regards

Geraldine

-- 

Geraldine TEXIER

Associate Professor
IRISA/ Reop Team

Hello All,

Thanks,

Shwetha

---

From: Rene Struik <[email-masked]>
Date: Fri, 06 Mar 2015 10:06:15 -0500

Hi Pascal:

BTW - my own (very small) comment was triggered by a last-minute change 
you personally made to the consensus text of the 6TiSCH security design 
team, without any consultation or notification. I do not know why you 
did this, but the resolution is also simple: simply retract that.

You were on the call where we finalized this text (excerpt below). I 
attach hereby the results of the homework assignment alluded to in the 
first sentence of #5 of the minutes of that call. As you can see, this 
includes a careful analysis of join process text. By the amount of red 
text and annotated remarks, you can see why we ended up with the text as 
is: there were too many problems and non-working concepts with 
alternatives (I am totally transparent here).

It would be good to respect consensus, certainly as co-Chair.

[excerpt of minutes of Thu January 22, 2015 6TiSCH Security call, see: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00413.html]

1. Attendance:
Michael Richardson, Subir Das, Tero Kivinen, Giuseppe Piro, Pascal 
Thubert, Rene Struik
[..]

5. Input 6tisch security to the architecture draft 
(draft-ietf-6tisch-architecture-04)
RS reported on the outcome of the homework assignment of the 6tisch 
security call of the previous week (Jan 14, 2015). He had scrutinized 
the three text proposals that were on the table and had reviewed those 
with aim of establishing which elements reflected consensus of the 
6tisch security group and also suggested "consensus text" the text in 
the document titled "join process text - suggested text for architecture 
document, v2 (Rene Struik, January 21, 2015)" (available via the Google 
Drive link). He suggested to go over the (hopefully) consensus text, 
identity areas where this could be improved on the call, and then post a 
revision reflecting this as input to the architecture document prior to 
the 6tisch call of the next day (Friday January 23, 2015, 11am EST). 
Further comments, if any, could then be made as part of the review 
process of the architecture doc, rather than rehashing this more now, 
thus allowing Pascal Thubert to move forward with the architecture 
document and the 6tisch security group to focus on drilling down on more 
detail of the join protocol itself. MR suggested he was happy with this 
process.

RS briefly went over the document, identifying some feedback received 
from Subir Das and Yoshi Ohba by email. He also highlighted that he had 
incorporated the suggestion by MR on the previous call to 
cross-reference some actual protocols that could be considered. A brief 
discussion ensued.

PTh suggested that it would be good to add some language to the effect 
that the actual decision of the joining node to become part of the 
network may depend on authorization of the network itself. It was 
decided to leave out further minutiae, such as "authorization of the 
root of the RPL network", etc., so as to focus on the join process 
itself, without adding too much routing protocol baggage for now. RS 
suggested that this would also avoid issues that could arise in case 
distributed JCE's would be considered, which would not correspond to a 
single, fixed node. SD suggested to swap the order in which the join 
protocol phases and the device roles were presented in the text. He 
further on noted that some of the terminology re joining node, join 
assistant, and JCE was not entirely in with what was depicted in Fig. 1. 
Finally, he suggested a few small edits, such as clarifying that a 
"one-hop neighbor" would be one "radio hop" away and not one IP hop, etc.

RS agreed to try and incorporate this feedback and post a revised text 
document, aimed to be ready for inclusion with the architecture document.
[end of excerpt]

Rene

==

and from the comment, I’m not even seeing a real consensus there.

---

From: Rene Struik <[email-masked]>
Date: Fri, 06 Mar 2015 10:18:06 -0500

Hi Pascal:

On 3/6/2015 9:52 AM, Pascal Thubert (pthubert) wrote:
> consensus, not your reading of the consensus at the calls that you 
> have organized, however great the work that is achieved there. We 
> really exposed the 6TiSCH group too late to that text. I think that 
> the security work really belongs to the next volutme of the 
> architecture, after we have rechartered and agreed upon what we will 
> cover.
>
> Second is that Jonathan’s comments really indicate to me that the text 
> is not even consensus within the group that the chairs named as DT. On 
> the side, the architecture should not only exemplify certificate 
> based. It must be made very clear that the art has a lot if not all of 
> PSK.
>
RS>>
I discussed Jonathan Simon's smallish comments yesterday with Kris 
Pister (who took his role in his absence). He fully agreed with the 
small suggested change, which did in no way materially impact the 
security text.

Your impression is simply that: your impression. The 6TiSCH security 
calls would have happily entertained a technical discussion on PSK-based 
techniques, however, over the course of more than one year, we have not 
seen a single technical proposal from you or others in that direction. 
We are still happy to see one, though. We did have some discussion on 
deployment scenarios, where the ability to mix-and-match devices from 
different vendors kind of made PSK-only techniques problematic. This was 
also confirmed by your colleague Michael Behringer at the time, when 
discussing semi-automatic device enrollment in a scalable (to the 
millions; not single light bulb - single switch) scenarios.
<<RS
>
> Third, about
> /> I think your statement on "//In particular, the only art that we 
> have been able to analyze is PSK, and there is still no documented 
> proof available to the IETF that we can do better on TSCH" is entirely 
> incorrect and not based on fact at all./
>
> This is utterly unhelpful. What would be helpful is that you indicate 
> the proof that we can use to demonstrate that the text in section 13.1 
> is actually workable; such reference would be a valuable addition to 
> the text. Even though, I’d move the text to annex.
>
RS>>
The text in Section 13 is an overview of the architectural flows 
involved with the join protocol. Most concepts have been presented at 
IETF-90 (Toronto) and at IETF-91 (Honolulu), when there was no real 
objection to this. Moreover, ISA SP100 uses similar notions, whereas the 
text in Section 13 closely mimics the w/HART flows. I am baffled that 
you now suggest this is all unworkable, without any proof point.
<<RS
> *Sent:* vendredi 6 mars 2015 15:42
> *To:* Pascal Thubert (pthubert); Shwetha Bhandari (shwethab); Thomas 
> Watteyne
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] (suggested disposition) Re: Last call for 
> have not been on most of the 6tisch security calls, but Thomas 
> Watteyne, the other co-Chair has been, who could confirm this.
>
> I think your statement on "In particular, the only art that we have 
> been able to analyze is PSK, and there is still no documented proof 
> available to the IETF that we can do better on TSCH" is entirely 
> incorrect and not based on fact at all.
>
> Best regards, Rene
>
>     My perception is that the problem is not there at all. In fact,
>     I’m inclined to remove 13.1 completely.
>
>     My problem with 13.1 is that it does not reflect the WG consensus
>     but a DT consensus, and from the comment, I’m not even seeing a
>     real consensus there.
>
>     In particular, the only art that we have been able to analyze is
>     PSK, and there is still no documented proof available to the IETF
>     that we can do better on TSCH.
>
>     My suggestion is midway:
>
>     - push 13.1 to annex
>
>     - add pointers to other security drafts (including yours and
>     Yoshi’s, do I miss any?)
>
>     - and move the definitions at the beginning of 13.1 in the
>     terminology draft.
>
>     I’ll be asking that question at the call today, and by default
>     will apply by cutoff time.
>
>     What do others think?
>
>     Pascal
>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     My suggested resolution to my comment was the simplest one: to
>     simply delete this 2nd para of Section 13. This would also make
>     Section 13 (minus the 2nd para) reflect confirmed consensus in the
>     6TiSCH security design team [see also minutes conf call of January
>     22, 2015:
>     I think it is somewhat odd to single out one individual security
>     draft in the Appendix and not include others, since it raises
>     questions as to what the criteria for inclusion and exclusion of
>     those drafts were. To avoid going down this path, I personally
>     would rather not give rise to those types of questions and simply
>     delete this.
>
>     Best regards, Rene
>
>         /   This volume only covers a portion of the total work that
>         is needed to /
>
>         I think the draft document draft-ietf-6tisch-architecture-05
>         is in relatively good shape.
>
>             I have reviewed the draft
>             draft-ietf-6tisch-architecture-05 and I support its
>             publication
>
>             Best Regards
>
>             Geraldine
>
>             -- 
>
>             Geraldine TEXIER
>
>             Associate Professor
>             IRISA/ Reop Team
>                 *From: *"Shwetha Bhandari (shwethab)"
>                 <[email-masked] <mailto:[email-masked]>>
>                 Please review and send in your comments / vote, this
>                 last call ends on 18th Feb.
>
>                 Thanks,
>
>                 Shwetha
>
>
>
>
>
>

---

From: Kris Pister <[email-masked]>
Date: Fri, 06 Mar 2015 08:57:59 -0800

Ted - thanks for the calm, clear words.

My reading of the text in 13.1 is that it is sufficiently flexible that 
it doesn't prevent
us from doing any of the things that I think are important based on past 
deployments,
and it allows substantially fancier things to be done as we figure them out.

Specifically, I believe that there is a way to live within the 
description of 13.1 and still do
1) PSK join with <= 4 802.15.4 frames exchanged between JN and JA
2) ECC-based certificate join with <= 4 802.15.4 frames exchanged 
between JN and JA
3) other stuff that people in the group want to do that will take > 10 
frames,
but will provide compliance with other standards of interest.

My only concern in the security working group is that we do not spend 
enough time
talking about 1) and 2).

ksjp

---

From: Kris Pister <[email-masked]>
Date: Mon, 09 Mar 2015 10:00:47 -0700

I just listened to the recording of the last 6tisch call and feel that I 
need to clarify my
position, since my name came up a few times in that call, and I wasn't 
able to attend.

What I wrote below is true: I don't have a problem with the 13.1 text.  
But that is
not because I believe that it is the consensus of the security design 
team.  The security
design team is dysfunctional.  I can't think of a single point of 
consensus that we've
had.  The last thing that I saw there that I liked was Michael's post on 
Nov 17
http://www.ietf.org/mail-archive/web/6tisch/current/msg02734.html
because he started off by acknowledging that there are probably going to 
be a bunch
of different ways to do security, from the simplest PSK that is barely 
better than no
security, up to financial-transaction quality.  That flexibility, and 
acknowledgement that there
might be different security levels suitable for different applications, 
seems like a good
starting point for further discussions.

ksjp

On 3/6/2015 8:57 AM, Kris Pister wrote:
> My reading of the text in 13.1 is that it is sufficiently flexible 
> that it doesn't prevent
> us from doing any of the things that I think are important based on 
> past deployments,
>> Consensus on a design team call is not working group consensus.   
>> Once the design team knows what they want to say, they have to say it 
>> to the working group and try to get consensus there.   So in this 
>> context there is nothing to which to object: it is your job now to 
>> listen to what the working group has to say and make whatever 
>> arguments need to be made to the working group as a whole.   It is 
>> entirely appropriate for the working group to overrule the design 
>> team in the process of getting to consensus, and you should make your 
>> arguments with that in mind.
>>
>> To go a bit further, just to be as clear as possible, general assent 
>> on an interm virtual meeting call is not working group consensus.   
>> Working group consensus happens on the mailing list.
>>