Minutes for 6TISCH at interim-2016-6tisch-7

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes for 6TISCH at interim-2016-6tisch-7
State Active
Other versions plain text
Last updated 2016-04-22

Meeting Minutes

   # Minutes, 22 Avril 2016 interim, 6TiSCH WG #

    Note: timestamps in PST.

Connection details

* Date: 7-8am Pacific:
* Webex link:
* Webex recording:
Recording password: tDm2jtS3 * Meeting Slides:
https://bitbucket.org/6tisch/meetings/ * Wiki:
https://bitbucket.org/6tisch/meetings/wiki/160422_webex * Slides:

Taking notes _(using Etherpad)_

1. Thomas Watteyne
1. Pascal Thubert
1. Diego Dujovne


1. Thomas Watteyne
1. Pascal Thubert
1. Alex Pelov
1. Chonggang Wang
1. Diego Dujovne
1. John Mattson
1. Lohith Y S
1. Ludwig Seitz
1. Maria Rita Palattella
1. Michael Richardson
1. Nicola Accettura
1. Pat Kinney
1. Rashid Sangi
1. Qin Wang
1. Robert Cragie
1. S.V.R. Anand
1. Savio Sciancalepore
1. Sedat Gormus
1. Seema Kumar
1. Xavi Vilajosana
1. Zhuo Chen

Action Items

* Pascal to clean up the mailing list based on voluntary participation
* Authors of 6P and SF0 drafts to publish 00
* Authors of OSCOAP to join the security DT ML


* Administrivia [2min]
    * Approval agenda
    * Approval minutes IETF 95
* Pending WG doc Adoptions
* Security Bootstrap Michael Richardson [10mn]
* OSCOAP  Goran Selander [40mn]
* AOB [1min]


* Administrivia _[2min]_
    * Approval agenda
    * Approval minutes minutes IETF 95
    > No issues raised. Agenda and Minutes Approved

* Pending WG doc Adoptions

    * New draft close to adoption - address protection associate unique id on
    the 6lopwan registration * Call for adoption for SF0 and 6P nothing against
    them. * Pascal asks Raise hands? Against? * Michael Richardson: For the
    adoption. Afterwards, other SFs can be created. * Chonggang Wang: I sent
    comments on metadata on 6P, should be addressed. Section 6: TODO Metadata
    Definition. * Pascal Thubert: The working group must decide what to be
    done. * Opposition to adoption? No. Both drafts are adopted. * Republish on
    IETF with the ietf name change * Do not make any changes.

* Security Bootstrap Michael Richardson [10mn]

    * we should restart with the security ML
    * Michael will indicate on the sec-ML who is on there
    * If people want to join the ML, let Michael know
    * Michael: to Alex Pelov: Send invitation to the ML. I will reach you.

* OSCOAP  Goran Selander [40mn]

    * John Mattson: Object Security solution not standardized yet in CoSe for
    CBOR. * Can be used between one or intermediate proxies. * COSE object to
    create a new COAP option called security. Independent from transport. Small
    footprint. * Small messages. End-to-End security, shared key, small number
    of exchanges. Current plan to ask for adoption in CORE WG in Berlin. * COSE
    is binary JSON. Add this object to the COAP header. Does not rely on any
    other identifiers to encrypt or decrypt. * Example (Slide 13) Both in the
    request and in the response. * Low footprint. Computing overhead low,
    message overhead low. * Alex Pelov: How to add support on COAP * Need base
    COAP plus this option. * IDENTIFIER (variable length) 1 byte sequence
    number (variable length) 2-3bytes COSE encoding 7-8 bytes message integrity
    CCM 8 bytes missing last item) * Ludwig Seitz from chat: Transaction
    identifier 5 bytes, AES-CCM-8 tag 8 bytes COSE overhead 9 bytes. * PT:
    integrity check allowed by 6lowpan. you can save two bytes on UDP. * CW:
    Comparison of this solution from DTLS? * John: Processing message size,
    number of round-trips, computational complexity. TODO. Will send it to the
    ML. * John Mattson: New Security  requirements scenario 1 and 2. Scenario 2
    node doing caching. * Ludwig Seitz: Master students working. California
    library C code for embedded still under work release May 10th. People to
    maintain this code. * Thomas Watteyne: Why not CCM-4? MAc layer CCM-4 tag.
    8 bytes may be too much. Security risk? * Alex Pelov: Have the possibility
    to have a 4 byte tag? * The only difference is how many packets to brute
    force before obtaining access. CCM-8? 1 out of 4 billion * PT: Can we make
    the L2 security less expensive if we have this? * Thomas Watteyne: MIC:
    Auxiliary security DSN and MIC at the end. 4 to 10 bytes. * Robert Cragie:
    I think CCM_8 comes from TLS. We suggested use of 4 byte tags for CCM AEAD
    cipher suites but the authors did not want to use that. GCM AEAD cipher
    suites don't even specify the _8 option. Using a 4 byte MIC on a link layer
    in a confined network is a different use case to Application layer
    security. * Michael: Layer3 (meaning and above NOTNT) Only one per packet.
    Payload is already 1000 bytes layer 2 on every packet. not reduce layer 2
    security, repeat it on every fragment. Cannot eliminate in that  layer. *
    Michael Richardson: DTLS can set that up? * John Mattson Need to implement
    heavy DTLS, it would be better to define this preset key exchange * Thomas
    Watteyne: How to securely bootstrap a network without DTLS. * John Mattson:
    Slide 18, graph incomplete. * Robert Cragie: In answer to Michael's
    question whether you could use DTLS to establish security context for COSE
    - I guess you could. You would have to export the master key and then close
    the DTLS session. However, there is no obvious binding between the
    established key and its use in subsequent COSE-based security. * Michael
    Richardson: Simultaneously multiple transactions? * John Mattson: Can be
    (?) * Michael Richardson: 15.4 IE or on IP? * John Mattson: Can run on IEs,
    where COAP runs, it runs. * Robert Cragie: Only encryption: never. Only
    integrity check: Possibly * Thomas Watteyne: (Missed question) * Thomas
    Watteyne: Very good summary on Appendix A, examples. * John Mattson: This
    will help with my work on 6tisch ML

      # Thomas shares screen:

    * We discussed with Goran in Buenos Aires. The idea leverages a central
    Join coordination entity and PSK, each key associated to a node; a joining
    node talks to a Join Assistant and through it sends a POST, with an opaque
    that is sent to the JCE. The JCE validates the encrypted content and
    authorizes. * Thomas Watteyne: Now that JCE knows the device is there. Now
    there is a need for key K2 for data. THere may be a preprovision. But the
    JCE could also post K2 to the device using OSCOAP and the device is now
    operational for data. * Michael: Happy that the OSCOAP is that far along *
    Thomas Watteyne: authors please join 6TiSCH security design team. Note that
    there is not much 6TiSCH specific Apart from mentioning K2. * John Mattson:
    Very happy to hear feedback and hope this is adopted in 6tisch. We will
    join the security design team. * Robert Cragie: Re. OSCOAP on 6tisch slide:
    I think you would need at least a 3-way challenge-response handshake at the
    beginning. Request/response is not probably not enough

* AOB [1min]

    * Thomas Watteyne: next call in 3 weeks. May 13th.