[6tisch-security] DRAFT minutes from meeting 2016-09-13

[Michael Richardson <[e-mail]>]

To remind: we are meeting 2016-09-27, at 1400UTC (10am EDT).
We meet at: https://jitsi.tools.ietf.org/6tischSecurity
Please try your browser, firewall/etc. beforehand. The room is open.
We will use audio only, so feel free to mute your camera, and use the shared
etherpad within JITSI.

Agenda for this week:
0) note well.
1) approval of agenda
2) minutes from last week.
3) work to do during meeting:
   time sequence diagram for document
      draft-richardson-6tisch-dtsecurity-secure-join
4) possibility to use GRASP from Join Assistant to JCE, since DAR/DAC is off
   the table.


DRAFT MINUTES from 2016-09-13:
AGENDA
   0) hello and Note Well.
   1) review since IETF96.
      a) updates on crypto?
      EDHOC -- dialogue with some crypto people about freshness (of
      initiator) with two-pass protocol. The issue you need to know it's not a
      replay.

        -- go for SIGMA-I protocol.
        SIGMA-I is a design pattern for crypto protocols:
                http://webee.technion.ac.il/~hugo/sigma.html

        Provides identity protection against active attacks of initiator and
        passive attacks of responder.  Three passes, but the total EDHOC +
        OSCOAP can be embedded in two round trips. Similar to what TLS 1.3
        has done.

              -- plan to have an update on document for review, then CFRG
                 review.

      Q: any plans to submit to 802.15.9, or specify how to use it with 15.9?
      A (Tero): need to have KMP defined somewhere (i.e. IETF).  IEEE
            802.15.9 has small appendix to explain how to derive keys for 15.4.  To
            get a number to use, there is an IEEE 802.15 Assigned Number
            Authority. There is a form to do this.
            Some stuff is moving from 802.15.9 to 802.15.12 (upper layer
            interface).

            EDHOC will remain in ACE WG.

      b) updates on network logistics.
        - discussion about whether JCE managed, centrally initiated secured CoAP for join traffic
        - TW suggests that join traffic, if on a seperate track, can be grown
          in bandwidth as required.  So even though 6p can add cells, it can not
          grow all of the cells.

        - TW explains that pledge becomes associated to JA's schedule, and at
          the beginning of the minimal slot, it wakes up to listen, (Rx/Tx).

        - initial show of interest should be part of the protocol, and should
          be part of the security protocol description.

MCR wrote an initial ACTION required:
      a) PRO of centrally initiated
      b) CON of centrally initiated
      c) PRO of pledge initiated
      d) CON of pledge initiated

      TW: if we have a solution that has a lot of round trips, then it is
          better to sequence things.
      TW: if you have a 500-byte frame, then it will take ~5 slotframes to
          send this packet to next hop, possibly about 5s as the slotframe
          repeats each 1s.

      MCR: is there value of the Join Assistant to schedule the pledges/new nodes to initiate?
      TW: if there is multiple nodes talking to the same JA, then there is no contention.

   2) state of draft?
      https://datatracker.ietf.org/doc/draft-richardson-6tisch-dtsecurity-secure-join/
      https://github.com/ietf-roll/6tisch-secure-join ..


CONCLUSION from above discussion was that JCE initiated join protocol is
still possible, and is better from bandwidth planning point of view.




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