
From nobody Mon Aug 11 08:33:22 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD431A0669 for <6tisch-security@ietfa.amsl.com>; Mon, 11 Aug 2014 08:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.57
X-Spam-Level: 
X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.999, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wVZgwNgWHPT for <6tisch-security@ietfa.amsl.com>; Mon, 11 Aug 2014 08:33:12 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694071A0668 for <6tisch-security@ietf.org>; Mon, 11 Aug 2014 08:33:12 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C8AC320028 for <6tisch-security@ietf.org>; Mon, 11 Aug 2014 11:35:57 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 54AFB63AC9; Mon, 11 Aug 2014 11:33:11 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 436C9638D9 for <6tisch-security@ietf.org>; Mon, 11 Aug 2014 11:33:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6tisch-security <6tisch-security@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 11 Aug 2014 11:33:11 -0400
Message-ID: <29137.1407771191@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/FUfvPpBkPYhhH4w8-q5k27Ahw64
Subject: [6tisch-security] next steps
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 15:33:13 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


I am looking for options for next steps.

non-mutually exclusive options include:
1) continue with calls; have to find a new time as 10am Monday got eaten
   by nomcom2014 for me.

2) flesh out more of document; but it has many bits in it which are not
   strictly architecture, but rather delve into solution space.
   That needs to be split off into another document.
   I could use a co-author here to help (I'm looking at Max, I think)

3) figure out if the document should be adopted, or if the relevant text
   should simply be lifted into the 6tisch architecture document directly.
   There could be some WG Consensus calls on aspects of this.

4) after (2), ask to have the document go through a security directorate
   review, making it clear to them that this is not for direct publication.

=3D=3D=3D=3D=3D=3D=3D

I responded to Mike St.Johns review, during IETF90 week, but I would welcome
some additional comments and contributed text.   I think that we have to ha=
ve
a section on the various ways in which the DTLS session is authenticated
including:
  1) vendor rooted certificates with chains for ownership.
  2) one-time-ish ("QR") off-line authorization token.
  3) repeateable on-line authorization token.
  4) more complex enrollment systems.

I also don't know how how to interact with UCAN at this point.

I would welcome some discussion about next steps, particularly from chairs,
From=20UCAN BOF chairs, and anyone else.


=2D-
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU+jiNICLcPvd0N1lAQJWlQgAwzBYJHv1ohn8KIMM2g9ecrw1/SCGBzTg
R3pS6AYQ5DCOixBMLkP25yFtwGANAYwbCW4Z5jP4MOhWFnhpb3DIb1wJ4moa+zqt
1l3v10mtd1LPaxNW8fwJCaCoLVVGvTQFTpd6hLlk5X944ii5iG8gc8JWkJ7iE0mJ
FY5+QMuBmiO1SWN5ov3I2mRTj0EFopHNJVu3oMzbUUEXl/9/ywLb107LUYmw/EKI
e0FEtfQhn7+HGGvf6dsWHx+o7wLZJ7N3BeAPKYsjanZUdH+0E+VQT5cboctUf4XD
cb8BT+eF368Y+t2yyBUSzqXZRzwl1xHKyome05aOT+DVUTiJULs1aw==
=8Drs
-----END PGP SIGNATURE-----
--=-=-=--

