Subject: [6tisch-security] reminder of design team meeting today

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Dec 2017 08:51:23 -0500

etherpad:
https://etherpad.tools.ietf.org/p/6tisch-security?useMonospaceFont=true

Conference audio/video at https://appear.in/6tisch-coap-est-minimal

agenda:
        1) review of last time.
        2) what documents do we need to write?!?
        3) where will they be progressed?

See illustration of documents in next email.

DID WE HAVE A MEETING BEFORE 2017-11-27, or do I just have two sets of notes?

minutes from 2017-11-27:

Attendees
---------

- Michael Richardson (mcr)
- peter van der Stok (peter)
- Benjamin Damm (Time OK)
- max pritikin MP)
- Mališa Vučinić
- Thomas Watteyne
- Tengfei Chang

Agenda
------

The agenda is loose, but:

0) scheduling discussion
every 2 weeks proposed
this time slot
no dissent

1) recap of IETF100, things arising from meeting

EST-coap likely to get adoped by ACE WG, given removal of BRSKI hard references.
Jim had remarks about proxying.
LWM2M situation is other use for EST-coap.
EST server standalone is an important application.

Jim says to get the DTLS proxy correct, and that would sufficient to do an adoption call.
   -> figure https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-02#section-6

2) frequency of these meetings

use of this meeting time, Panos + Peter are major authors.
MP: Panos indicates he couldn't join today but can join going forward. I've
    confirmed he has the invite.

3) state of 6tisch-minimal-security (briefly)
    MV: devoting all cycles to getting it out.
    * tagging of join traffic.  (AF43?)
    * MCR will send summary.

    Q: how well supported is DSCP/TOS setting for IPv6 socket API?
    MCR: I am pretty sure it's in the API, and can be done on a packet by packet basis even.

4) state of 6tisch-zerotouch-join (briefly)
  * CORE is getting to the point of being done with SID.
  * MCR to bring up question of assertion mapping
  * MCR how to we optimize the transmission of the client certificate?

MV: Jim has draft to encode certificate as CBOR, and option to have URL.
https://tools.ietf.org/html/draft-schaad-cose-x509-01
For (D)TLS this probably gets us into the realm of:
    https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/
or delayed authentication until post (D)TLS.

x5u:  This header parameter provides the ability to identify an X.509
      certificate by a URL.  The referenced resource can be any of the
      following media types:

5) plan for getting EST-COAPS to progress

we do not yet have a draft/presentation for zerotouch onboarding, except for 6tisch.

2017-11-27

present: mcr,

Minutes
-------

next meeting is Dec .11.
No meeting Dec. 25.
next meeting is January 8.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Dec 2017 09:29:25 -0500

Diagram for discussion:
https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/d61cbe958d37626fda9096084ec3906de46ea0fa/technology-components.svg?at=master&fileviewer=file-view-default

and attached.
See in particular the "yellow" section, which I just named for the next
available  nice colour my palette showed me.  I hesitate to give a name to
that constituency.

Perhaps I have mis-represented the desires, and maybe there is yet another
collection.  If "yellow" would be happy with JSON format vouchers, then it
would just be BRSKI over CoAP/DTLS.
(The savings is only a TCP stack, and reuse of CoAP)

On the other hand, I can see if you've bothered to do all of DTLS including
certificate handling, then having CMS is perhaps not that big a deal,
although I note that mbedtls (AFAIK) does not have CMS code.

I'm interested in the part in pink, with the caveat that we need to *try*
with DTLS in order to have enough data to justify OSCORE+EDHOC.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Dec 2017 22:00:16 -0500

BACKGROUND:

The original diagram presented to the 6tisch security design team this morning:

Revised diagram for discussion from discussion:

https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/092899562470eeecd5aaa72c60f0a6c474f28237/technology-components-v2.svg?at=master&fileviewer=file-view-default

and a copy at:
http://www.sandelman.ca/SSW/ietf/6tisch/technology-components-v2.svg

We have named the "yellow" portion as a new vertical, and called it:
   "Transition to constrained bootstrap"

I will add in RFCxxxx/I-D.ietf-xyz to the boxes later today.
Maybe a roadmap/applicability document for iot-dir might explain it all.

I have added to the left, the 6tisch minimal-security, and I also added to
the bottom the set of join proxy technologies that have been considered/defined.

KEY POINT:
    We would up with the constrained bootstrap voucher format as yet-another-new
    document.  Here is a strawman document which is extracted from the
    6tisch-zerotouch-join document.
    The SID tooling has come along a lot in the past two weeks, btw.

    https://datatracker.ietf.org/doc/draft-richardson-anima-ace-constrained-voucher/

    (It took two revisions to make the yang nits happy, but I'm still missing
    5.1.2 SID values section)

There is a belief that this should be considered as new work for ANIMA.

Peter van der Stok is going to report if/who/what/where the
yellow/"transition to constrained bootstrap" document might be written.
It could be that it gets written outside of the IETF.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 12 Dec 2017 09:10:05 +0100

> It could be that it gets written outside of the IETF.
Thanks for the diagram; it became a bit more extensive since the last 
time I saw it.
About writing:
I will report first the interest in the CBOR voucher and stateless proxy 
document.
Decisions on the where and what of the yellow document need some time.

Peter