From nobody Mon Oct 20 06:52:22 2014 Return-Path: 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 D35861A8766; Mon, 20 Oct 2014 06:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 pmWTmWWDogSB; Mon, 20 Oct 2014 06:52:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9C01A8733; Mon, 20 Oct 2014 06:52:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E063B20012; Mon, 20 Oct 2014 09:52:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 979EF63A84; Mon, 20 Oct 2014 09:52:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 85E1163A82; Mon, 20 Oct 2014 09:52:05 -0400 (EDT) From: Michael Richardson to: 6tisch-security@ietf.org, 6tisch@ietf.org In-Reply-To: <17957.1413736225@sandelman.ca> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/epYVr0aXwGyUJlhCEP-ZgbIfosg Subject: Re: [6tisch-security] two 6TiSCH security working calls 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 13:52:20 -0000 --=-=-= I'm resending this, as it might not have made it off my tablet yesterday. Or maybe it's a duplicate. Michael Richardson wrote: > We will meet on *Tuesday* Oct 21 and 28 at 8am PDT. > Webex to be posted on Monday. This is a WORKING MEETING, please read: > https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-02 > I will post it to etherpad, and the goal is to EDIT this, fill in > missing text such that it is complete. Subsequently, we will rip the > document into two; one part to be patches into 6tisch-arch, and the > other for the 6top people. Meeting number: 645 146 419 Meeting password: timeslot Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Show toll-free dialing restrictions Access code: 645 146 419 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVEUThYCLcPvd0N1lAQLKLggAwwhxgjlg0wCbmCOqa+o31gb+vsPY0fYq gibc1A89fbvc0Y1goDWUh4d2vU6qxDCT15r+FHhcXBZWOpGYu1BrNXhaM4wa4+b8 Gmy3wk10W7S5n8fV8qQhXOJ6BiLpbfFyVYdC2Q3jjmrx2yIo0fGn9bAVnMBsc+6m VqxwYZJVUpbhKEXZwKAQSXDnZ5akatcTxqgQaRVQZ/lyTncN4FuYzBKdnP2qxh/O rjcqALeVxdfWYEG/RqO79KA+1rCtwD1OIwsAIoveudTCWaz7boYvhrJd8libpuGT OWrRwQJ/CiDqtm60wMFqz5h4jF8+FyhE0JD7jzAWeffN8j6gFPJHSA== =6vDz -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 20 08:08:01 2014 Return-Path: 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 0C6C51A8947; Mon, 20 Oct 2014 08:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 r3Q1gMoeiTaI; Mon, 20 Oct 2014 08:07:47 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503FE1A90CA; Mon, 20 Oct 2014 07:43:27 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id r10so4683625igi.14 for ; Mon, 20 Oct 2014 07:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=2A8f8VZWxBuEn5uwPqqAW69Aq+AtnnRrCNnwJh/P+94=; b=FPaGCYHM0L0Q6ARH3LZE0cjjIrvJMS6EbBEBp8xkM3EqgGmS/DBz7/2+Tf6m9bLMWG MbkP6hpDgxNOdSCFY0f3uATwEw1bmK7p8mwcK4AEFVSAyW8nzXpmJFos0GhgkaINWm+o rjFEUTusQ9hwHRQ76RT+Mytci5wFHHGcbrVKr3wCGBc+wJCjI0FiC/7COFTZvKaaW/yS 1J0JMH7danOJ4hoM7TRm0E9YmBcWCbji3Opx8QeJOVoW4RqxJm4EGKkv8SyyaJn5zPdi UCDxX9b1+eaLaXtcesVf4pmUMhfYOgDxFFMsWPRD9jq45DHmjPLpQHdgFiH/rAMLEcGx 5y2A== X-Received: by 10.50.134.131 with SMTP id pk3mr18588341igb.6.1413816206703; Mon, 20 Oct 2014 07:43:26 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id g7sm3888004igg.1.2014.10.20.07.43.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Oct 2014 07:43:26 -0700 (PDT) Message-ID: <54451F80.4020509@gmail.com> Date: Mon, 20 Oct 2014 10:43:12 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richardson , 6tisch-security@ietf.org, 6tisch@ietf.org References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <15813.1413813125@sandelman.ca> In-Reply-To: <15813.1413813125@sandelman.ca> Content-Type: multipart/alternative; boundary="------------000608080208060109020207" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/hz6M2jAsWbHYLIPljIcAu70TP0s Subject: Re: [6tisch-security] two 6TiSCH security working calls 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:07:51 -0000 This is a multi-part message in MIME format. --------------000608080208060109020207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Michael: I am surprised seeing your note below, given the notes on conf calls by the 6TiSCH Chairs in http://www.ietf.org/mail-archive/web/6tisch/current/msg02517.html. Best regards, Rene On 10/20/2014 9:52 AM, Michael Richardson wrote: > I'm resending this, as it might not have made it off my tablet yesterday. > Or maybe it's a duplicate. > > Michael Richardson wrote: > > We will meet on *Tuesday* Oct 21 and 28 at 8am PDT. > > > Webex to be posted on Monday. This is a WORKING MEETING, please read: > > https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-02 > > > I will post it to etherpad, and the goal is to EDIT this, fill in > > missing text such that it is complete. Subsequently, we will rip the > > document into two; one part to be patches into 6tisch-arch, and the > > other for the 6top people. > > Meeting number: 645 146 419 > Meeting password: timeslot > Audio connection: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > > Show toll-free dialing restrictions > Access code: 645 146 419 > Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------000608080208060109020207 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Hi Michael:

I am surprised seeing your note below, given the notes on conf calls by the 6TiSCH Chairs in http://www.ietf.org/mail-archive/web/6tisch/current/msg02517.html.

Best regards, Rene

On 10/20/2014 9:52 AM, Michael Richardson wrote:
I'm resending this, as it might not have made it off my tablet yesterday.
Or maybe it's a duplicate.

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > We will meet on *Tuesday* Oct 21 and 28 at 8am PDT.

    > Webex to be posted on Monday.  This is a WORKING MEETING, please read:
    > https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-02

    > I will post it to etherpad, and the goal is to EDIT this, fill in
    > missing text such that it is complete.  Subsequently, we will rip the
    > document into two; one part to be patches into 6tisch-arch, and the
    > other for the 6top people.

Meeting number:   645 146 419
Meeting password: timeslot
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Show toll-free dialing restrictions
Access code: 645 146 419
Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02


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






_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------000608080208060109020207-- From nobody Mon Oct 20 11:35:48 2014 Return-Path: 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 E2FFC1A902A; Mon, 20 Oct 2014 11:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Y2nL3sZlougO; Mon, 20 Oct 2014 11:35:42 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21091A8AF1; Mon, 20 Oct 2014 11:35:42 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id ft15so5488288pdb.16 for ; Mon, 20 Oct 2014 11:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=i0UFGN4S1TxmbJvuE6RF8K3OmdfnJjQxW+hiyLGKfDM=; b=OGCESz+jOLyVL4G6Y0d+4keQtX/T3jL7M39Wnuel+M3KO/oq3I7QMqolO8UCv1M8kF HV6fHbjXdNimtRioFHEPWxburDHgaM1BsBg0ftjbaJDV+ZG/Yi63v+CWZ83fECmrvCim 3fyz2s0ELAMa8Xc8nIljU2S80IwjsV6x45mRFFOE7sJBMEbGxtJ4pe5fUk9GpqDX7CH5 mINpxlq8afJKJ4jDd3sRm546UAvId08dp1sjR2qbHItpYy38b0EHVXmOJbiUnq9pKUeQ IdeMJre0C2wic8yJu7lPhXOqQC/eaJI5PBiV3jcFAixQtGUSNdNFpoFrXvlIXgxIf20+ xU9A== X-Received: by 10.66.66.163 with SMTP id g3mr3748934pat.152.1413830142379; Mon, 20 Oct 2014 11:35:42 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.250.169 with HTTP; Mon, 20 Oct 2014 11:35:21 -0700 (PDT) In-Reply-To: <54451F80.4020509@gmail.com> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <15813.1413813125@sandelman.ca> <54451F80.4020509@gmail.com> From: Thomas Watteyne Date: Mon, 20 Oct 2014 11:35:21 -0700 X-Google-Sender-Auth: ZjEXcWXexsMHgrdCsA_lDhL8rI8 Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=001a1134a13468ec120505defb92 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/sD8TmieXVqIaIUaeG-H5zEheHQo Cc: Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] two 6TiSCH security working calls 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:35:45 -0000 --001a1134a13468ec120505defb92 Content-Type: text/plain; charset=UTF-8 Rene, Thank you for keeping an eye on this. Please note that Michael's invitation is targeted at the 6TiSCH security DT to very specifically discuss one draft before this is presented to the 6TiSCH WG. Per https://www.ietf.org/iesg/statement/interim-meetings.html, I believe this working meeting falls under the following sentence "*This does not apply to meetings, conference calls, or jabber sessions for small design teams producing input to working groups.*". I hope this helps clarifying things. Thomas On Mon, Oct 20, 2014 at 7:43 AM, Rene Struik wrote: > Hi Michael: > > I am surprised seeing your note below, given the notes on conf calls by > the 6TiSCH Chairs in > http://www.ietf.org/mail-archive/web/6tisch/current/msg02517.html. > > Best regards, Rene > > > On 10/20/2014 9:52 AM, Michael Richardson wrote: > > I'm resending this, as it might not have made it off my tablet yesterday. > Or maybe it's a duplicate. > > Michael Richardson wrote: > > We will meet on *Tuesday* Oct 21 and 28 at 8am PDT. > > > Webex to be posted on Monday. This is a WORKING MEETING, please read: > > https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-02 > > > I will post it to etherpad, and the goal is to EDIT this, fill in > > missing text such that it is complete. Subsequently, we will rip the > > document into two; one part to be patches into 6tisch-arch, and the > > other for the 6top people. > > Meeting number: 645 146 419 > Meeting password: timeslot > Audio connection: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > > Show toll-free dialing restrictions > Access code: 645 146 419 > Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > > _______________________________________________ > 6tisch-security mailing list6tisch-security@ietf.orghttps://www.ietf.org/mailman/listinfo/6tisch-security > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --001a1134a13468ec120505defb92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rene,

Thank you for keeping an eye on t= his. Please note that Michael's invitation is targeted at the 6TiSCH se= curity DT to very specifically discuss one draft before this is presented t= o the 6TiSCH WG.

Per=C2=A0https://www.ietf.org/iesg/sta= tement/interim-meetings.html, I believe this working meeting falls unde= r the following sentence "This does not apply to meetings, conferen= ce calls, or jabber sessions for small design teams producing input to work= ing groups.".

I hope this helps clarifyin= g things.

Thomas

On Mon, Oct 20, 2014 at 7:43 AM, Rene S= truik <rstruik.ext@gmail.com> wrote:
=20 =20 =20
Hi Michael:

I am surprised seeing your note below, given the notes on conf calls by the 6TiSCH Chairs in http://www.ietf.org/mail-archive/web/6tisch/curr= ent/msg02517.html.

Best regards, Rene


On 10/20/2014 9:52 AM, Michael Richardson wrote:
I'm resending this, as it might not have made it off my tabl=
et yesterday.
Or maybe it's a duplicate.

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > We will meet on *Tuesday* Oct 21 and 28 at 8am PDT.

    > Webex to be posted on Monday.  This is a WORKING MEETING, please r=
ead:
    > https://tools.ietf.org/html/draft-richard=
son-6tisch--security-6top-02

    > I will post it to etherpad, and the goal is to EDIT this, fill in
    > missing text such that it is complete.  Subsequently, we will rip =
the
    > document into two; one part to be patches into 6tisch-arch, and th=
e
    > other for the 6top people.

Meeting number:   645 146 419
Meeting password: timeslot
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Show toll-free dialing restrictions
Access code: 645 146 419
Meeting link: https://ietf.webex.com/ietf/j.p=
hp?MTID=3Dm026b87ec5a630ca1ec44f2e79329ba02


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






_______________________________________________
6tisch-security mailing list
6tisch-securi=
ty@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=

_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security


--001a1134a13468ec120505defb92-- From nobody Mon Oct 20 22:12:49 2014 Return-Path: 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 1C5621AD04B; Mon, 20 Oct 2014 22:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gOIVmJj-BUAo; Mon, 20 Oct 2014 22:12:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438081AD040; Mon, 20 Oct 2014 22:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1492; q=dns/txt; s=iport; t=1413868365; x=1415077965; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NGtIr1HtSo0BnaShm/GfnFYZ4uBbfaMS/h/P1CE+Nk0=; b=V/m4eZ6YgQWnay4HzFKjLfcmjGs9r9Yrg40XgVxCOu6MUelu77P2JSjM 0RWDfQhbxK/Ip0ntZ8UYUf+XeA5tgMRdJHOQ6CLhAoGPwuUdMV+i2fGpY x6Y/NxjJDFc2Zj/esH4eOKCnCx7TYdH7VNxmsT4Cqn6LOKeoL91aJ+KMo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFALPqRVStJV2Y/2dsb2JhbABCFwOCayNTWATMDIdLAoENFgF9hAMBAQRmJQEIGBQEDDwkAQIBAwESiD8BDDe1OY8jAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNDgGCfjQXEQeEMwWSAYRGhxOBMINGgy2Nf4IOgRZTbAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,760,1406592000"; d="scan'208";a="88858778" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 21 Oct 2014 05:12:44 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9L5CiEu010224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 05:12:44 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 00:12:44 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch-security] two 6TiSCH security working calls Thread-Index: AQHP7G0UCzTPNCcX8k2gcS6xNZHnIJw54OWA Date: Tue, 21 Oct 2014 05:12:43 +0000 Message-ID: In-Reply-To: <15813.1413813125@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.85.206] Content-Type: text/plain; charset="Windows-1252" Content-ID: <52649289C598914983F3CF5F95D3F79A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ZQ2qcRQpbkdygFEJiGhXekt2OR4 Subject: Re: [6tisch-security] two 6TiSCH security working calls 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 05:12:47 -0000 Hi Michael, I did not see this in time for this week so will miss tomorrow=B9s call but will try to make next week=B9s session. I will try to review the draft and provide feedback=8A.will look forward to the notes from tomorrow=B9s discussion. Thanks, Nancy On 10/20/14, 6:52 AM, "Michael Richardson" wrote: > >I'm resending this, as it might not have made it off my tablet yesterday. >Or maybe it's a duplicate. > >Michael Richardson wrote: > > We will meet on *Tuesday* Oct 21 and 28 at 8am PDT. > > > Webex to be posted on Monday. This is a WORKING MEETING, please >read: > >=20 >https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-02 > > > I will post it to etherpad, and the goal is to EDIT this, fill in > > missing text such that it is complete. Subsequently, we will rip >the > > document into two; one part to be patches into 6tisch-arch, and the > > other for the 6top people. > >Meeting number: 645 146 419 >Meeting password: timeslot >Audio connection: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > >Show toll-free dialing restrictions >Access code: 645 146 419 >Meeting link:=20 >https://ietf.webex.com/ietf/j.php?MTID=3Dm026b87ec5a630ca1ec44f2e79329ba02 > > >-- >Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > From nobody Tue Oct 21 07:13:55 2014 Return-Path: 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 AD4EF1A6F51 for <6tisch-security@ietfa.amsl.com>; Tue, 21 Oct 2014 07:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01, WEIRD_PORT=0.001] autolearn=ham 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 Y0AEHrBvVAwF for <6tisch-security@ietfa.amsl.com>; Tue, 21 Oct 2014 07:13:51 -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 CD0D41A1B80 for <6tisch-security@ietf.org>; Tue, 21 Oct 2014 07:13:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4428820012 for <6tisch-security@ietf.org>; Tue, 21 Oct 2014 10:14:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6481A63A84; Tue, 21 Oct 2014 10:13:50 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5023263A21 for <6tisch-security@ietf.org>; Tue, 21 Oct 2014 10:13:50 -0400 (EDT) From: Michael Richardson to: 6tisch-security@ietf.org In-Reply-To: <17957.1413736225@sandelman.ca> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/X_BEjoZuxAdovAuLgWrtAHkScj8 Subject: Re: [6tisch-security] two 6TiSCH security working calls 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:13:53 -0000 --=-=-= Etherpad for working call today: http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt base work today: - recap of plans for document (10minutes) specific sections to review today: section 3. specific sections to address today: 4.2. implementation cost (storage of security material, computational cost) 4.3. denial of service other communication impacts of security protocol mechanics 10. slotframes to be used during join how is this communicated in the (extended) beacon. 14. Posture Maintenance (SACM related work) ====== next week: section 5 extended, intended as specific text for architecture document, going into a new section 6.6 of 6tisch-architecture, as well as populating section 11 (Security Considerations) of 6tisch-architecture from section 4 of 6tisch-6top. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVEZqG4CLcPvd0N1lAQKMyAf9HteS/o4MV9gF+93POFzmzyUu2smyjq9B j9FBecbrOLPcMxmzM0X8VT+j7YLXdAzOs/nJwDGivd7CApeJW+E6xyiv++FM6go4 CSTWccmu0G9tWBctp6COdN1btlYTITqjRBHiy+gS1W/tQgW7Oyi80/fyxWIaQLB6 rwsOvYZEo67DcG9JIgRAbW1RfdXorBADScRD6q6vdavyOWqbXeQr/RDSEWrR38p5 /ZObS//V5+vz5YzEOKO2s7dsSgeFEaOSQzkLtvZWEYFsjgkCH7blupINpOjKz4mO yqwqq4shCUnujsbXSQpjuXRqrTKlrMn4krafuSDI5Xf9mpNxxJaZ+A== =r0+P -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 21 11:56:34 2014 Return-Path: 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 770191A87ED for <6tisch-security@ietfa.amsl.com>; Tue, 21 Oct 2014 11:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 uR2vP5q0_APg for <6tisch-security@ietfa.amsl.com>; Tue, 21 Oct 2014 11:56:30 -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 0EA3B1A87DF for <6tisch-security@ietf.org>; Tue, 21 Oct 2014 11:56:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6982520012 for <6tisch-security@ietf.org>; Tue, 21 Oct 2014 14:57:20 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 52F6363A84; Tue, 21 Oct 2014 14:56:28 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 395C763A21 for <6tisch-security@ietf.org>; Tue, 21 Oct 2014 14:56:28 -0400 (EDT) From: Michael Richardson to: 6tisch-security@ietf.org In-Reply-To: <6219.1413900830@sandelman.ca> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/_Bm-WnEWqSpWsjIvV5F0YNHpSvw Subject: Re: [6tisch-security] two 6TiSCH security working calls 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:56:32 -0000 --=-=-= Michael Richardson wrote: > base work today: - recap of plans for document (10minutes) > specific sections to review today: section 3. Attending today's meeting was: - Thomas Watteyne - Michael Richardson - Kris Pister - Mike Seewald - Pat Kinney - Subir Das 1) we got started 10 minutes late, and reviewed what the purpose of the draft-richardson-6tisch-security-6top document was. There are two places for this text. a) into the 6tisch-architecture (or possibly a new document, as per the WG) b) into the 6tisch-6top document for the actual objects to adjust. c) into some other documents that might wind up in ANIMA. 2) we worked on section 3. we added some terms to the glossary and struggled with the "network-wide" shared symmetric key that many other details cryptographic key agreement protocols assume exists in order to authenticate exchanges. 3) we discussed whether or not we could use the 6top-over-15.4 Information Elements (IE) to do security bootstrapping, and concluded that we can not, as on the JOIN mac-key which authenticate that process would be well known. 4) we discussed the question of end-to-end, JCE<->JoiningNode communication, and the relative merits of the four possibilities outlined in section 3, page 6. We agreed that option (1) [ipip] was a poor choice, and that while option (4) was a really good choice, it might not be possible. We were left with whether a new DODAG or the existing base DODAG was the right answer. 5) we concluded that for self-organizing (no PCE) 6tisch networks, that per-pair L2 keys were very important due to the use of mac-layer IE to do schedule updates. This has a code and energy impact on nodes in that they need to support one of the per-pair mechanisms listed on page 5 (section 3)[MLE,802.15.9,ohba-6tisch-security,piro-6tisch-secuirity]. Not only is there a code space requirement, but there is also the need to have enough non-volatile storage to keep all of the (unique) keys to talk to each of one's neighbours. The upshot of this is that if you want to simplify the motes further, then having a PCE/JCE is an effective way as the motes need only maintain a single DTLS/CoAP/6top security association with the PCE, and the L2 network key could be common across the entire network. 6) we did not finish discussion of section 3, and we will come back to that next week, and also talk about what is in the packets 10-13, and if we can cache anything that would reduce join traffic. we did dicuss intensitivity of join traffic, and how the JCE can control how many nodes (and in which order) they join. 7) I will provide an overview in the Oct. 24 group call, and I will revise the document slightly for next week. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVEasWYCLcPvd0N1lAQIKbAgAgwXktmAt0yTUUglpudqicuIQF7oL1F0P eqzHDdgTy33i+8nC7yoVWnd0ZewlgNVNMr0fx1ZnAt5lTp+q2wQ0AGPbLXbG4seX VuQbPm9JwELQ1jyqmXtTcXwmW2MtLUDpcE2C4a0XJAnfjFztWIZ1fof/H1Ajcppb jpbvuMxsJTQTAhGmhYk446j56q/qEUjAGYRLbFcoI8HaMRvIaouMe5RYui4i/0JR nvmpMCquip8nK+nvBYrICEOoeJFHEmq99wQKvnuRickeMbFx++zi9MdzQok5TSOx J34tLXGGB5WZwQg//b+yQcUE5MeRrz4ltlmVShlFnW5K25DOlTTmfQ== =GGoX -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 26 13:05:54 2014 Return-Path: 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 824721A1A82 for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 bIdTgNRyfWSF for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 13:05:46 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E621A1A7E for <6tisch-security@ietf.org>; Sun, 26 Oct 2014 13:05:44 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id g10so4308625pdj.24 for <6tisch-security@ietf.org>; Sun, 26 Oct 2014 13:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=8wHMFcTMzWsZze4Kq56bG//9Bm2gj/mEUq97V90AHiQ=; b=MxTkTqI2gtMlCwyYZpP5J00IRCcf4oTJK4QOJVfnxMzGi3aYqZGPMFnSnGYOc9b5fY We9vTGytaJJGPURJbtyKzr0jTATlQfwlEQjQ8hXJ2RmXEwppBnW1bmLcxvZKx/tmcWPd az+Xk3FVf3lh4wGapOLICJUlRTgV1OjgzeBz5C+pv5SIPFrAgkfZfDZh56tv90Ck72YQ bbHGvTsGqwd6tg/YhFweMXUyIJFkhkR6gphy6KqMHPBMLekOIFNjYN6vsf1n+fsVfYHV viLK33GPv2ybQ9ASVQcXNjG0cYSB1mkr6ZG2shxAuRZ8uF7ac/qYdF84YwimBqheBtMl fIXQ== X-Gm-Message-State: ALoCoQlAmO1vbz4QJMPusQxJA0GfOx4J6o15mnEXTMlPSBTo79y//B6EawfFeZYgGc8FeL1Gm3S2 X-Received: by 10.70.48.202 with SMTP id o10mr19616216pdn.63.1414353944654; Sun, 26 Oct 2014 13:05:44 -0700 (PDT) Received: from [10.0.0.3] ([98.210.76.194]) by mx.google.com with ESMTPSA id x15sm8930176pbt.91.2014.10.26.13.05.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 13:05:43 -0700 (PDT) Message-ID: <544D5408.7010304@berkeley.edu> Date: Sun, 26 Oct 2014 13:05:28 -0700 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson , 6tisch-security@ietf.org References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> In-Reply-To: <32378.1413917788@sandelman.ca> Content-Type: multipart/alternative; boundary="------------000207050404010109080507" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/5JRxJ-O3byHPEue2ZJKk5wOJvrA Subject: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 20:05:51 -0000 This is a multi-part message in MIME format. --------------000207050404010109080507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael - I'm trying to get back up to speed on the security discussion, so forgive a few possibly out-of-date questions. -------------------------------------------- #1 Is this a correct statement of the start and end states? The mote starts with some authentication material, either 1) a pre-shared join key or 2) a certificate The JCE starts with either 1) the same pre-shared join key as the mote (possibly tied to the joining mote MAC ID, possibly unique, ...) or 2) a certificate The mote ends up with either 1) a single network-wide L2 key for the production network or 2) multiple L2 keys for the production network, each associated with one or more neighbors -------------------------------------------- #2 I'm a little confused on what's happening with flows in Figure 1. If I remember Jonathan's presentation correctly, I think that he was hoping to use packets 2 and 3 as a short cut to minimize the time and effort required for a DTLS PKI based exchange. If that's the case, then does it make sense to talk about a JCE-initiated session in packets 10 and 11? It seems like the joining mote has already said with packet 2 "hey, I speak short cut DTLS with secp256r1 - can you send me the JCE's public key?" or something like that. Yes? ksjp On 10/21/2014 11:56 AM, Michael Richardson wrote: > Michael Richardson wrote: > > base work today: - recap of plans for document (10minutes) > > > specific sections to review today: section 3. > > Attending today's meeting was: > - Thomas Watteyne > - Michael Richardson > - Kris Pister > - Mike Seewald > - Pat Kinney > - Subir Das > > 1) we got started 10 minutes late, and reviewed what the purpose of > the draft-richardson-6tisch-security-6top document was. > > There are two places for this text. > a) into the 6tisch-architecture (or possibly a new document, as per the WG) > b) into the 6tisch-6top document for the actual objects to adjust. > c) into some other documents that might wind up in ANIMA. > > 2) we worked on section 3. > we added some terms to the glossary and struggled with the > "network-wide" shared symmetric key that many other details cryptographic > key agreement protocols assume exists in order to authenticate exchanges. > > 3) we discussed whether or not we could use the 6top-over-15.4 Information > Elements (IE) to do security bootstrapping, and concluded that we can not, > as on the JOIN mac-key which authenticate that process would be well > known. > > 4) we discussed the question of end-to-end, JCE<->JoiningNode communication, > and the relative merits of the four possibilities outlined in section 3, > page 6. We agreed that option (1) [ipip] was a poor choice, and that > while option (4) was a really good choice, it might not be possible. > We were left with whether a new DODAG or the existing base DODAG was > the right answer. > > 5) we concluded that for self-organizing (no PCE) 6tisch networks, that > per-pair L2 keys were very important due to the use of mac-layer IE > to do schedule updates. This has a code and energy impact on nodes > in that they need to support one of the per-pair mechanisms listed on > page 5 (section 3)[MLE,802.15.9,ohba-6tisch-security,piro-6tisch-secuirity]. > > Not only is there a code space requirement, but there is also the need > to have enough non-volatile storage to keep all of the (unique) keys to > talk to each of one's neighbours. > > The upshot of this is that if you want to simplify the motes further, > then having a PCE/JCE is an effective way as the motes need only maintain > a single DTLS/CoAP/6top security association with the PCE, and the L2 > network key could be common across the entire network. > > 6) we did not finish discussion of section 3, and we will come back to > that next week, and also talk about what is in the packets 10-13, > and if we can cache anything that would reduce join traffic. > > we did dicuss intensitivity of join traffic, and how the JCE can > control how many nodes (and in which order) they join. > > 7) I will provide an overview in the Oct. 24 group call, and I will > revise the document slightly for next week. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security --------------000207050404010109080507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Michael - I'm trying to get back up to speed on the security discussion, so forgive a few
possibly out-of-date questions.
--------------------------------------------
#1 Is this a correct statement of the start and end states?

The mote starts with some authentication material, either
1) a pre-shared join key
or
2) a certificate

The JCE starts with either
1) the same pre-shared join key as the mote (possibly tied to the joining mote
MAC ID, possibly unique, ...)
or
2) a certificate

The mote ends up with either
1) a single network-wide L2 key for the production network
or
2) multiple L2 keys for the production network, each associated with one or more neighbors
--------------------------------------------
#2 I'm a little confused on what's happening with flows in Figure 1.  If I remember
Jonathan's presentation correctly, I think that he was hoping to use packets 2 and 3
as a short cut to minimize the time and effort required for a DTLS PKI based exchange.
If that's the case, then does it make sense to talk about a JCE-initiated session in
packets 10 and 11?  It seems like the joining mote has already said with packet 2
"hey, I speak short cut DTLS with secp256r1 - can you send me the JCE's public key?"
or something like that.  Yes?

ksjp


On 10/21/2014 11:56 AM, Michael Richardson wrote:
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > base work today: - recap of plans for document (10minutes)

    > specific sections to review today: section 3.

Attending today's meeting was:
- Thomas Watteyne
- Michael Richardson
- Kris Pister
- Mike Seewald
- Pat Kinney
- Subir Das

1) we got started 10 minutes late, and reviewed what the purpose of
   the draft-richardson-6tisch-security-6top document was.

   There are two places for this text.
   a) into the 6tisch-architecture (or possibly a new document, as per the WG)
   b) into the 6tisch-6top document for the actual objects to adjust.
   c) into some other documents that might wind up in ANIMA.

2) we worked on section 3.
   we added some terms to the glossary and struggled with the
   "network-wide" shared symmetric key that many other details cryptographic
   key agreement protocols assume exists in order to authenticate exchanges.

3) we discussed whether or not we could use the 6top-over-15.4 Information
   Elements (IE) to do security bootstrapping, and concluded that we can not,
   as on the JOIN mac-key which authenticate that process would be well
   known.

4) we discussed the question of end-to-end, JCE<->JoiningNode communication,
   and the relative merits of the four possibilities outlined in section 3,
   page 6.  We agreed that option (1) [ipip] was a poor choice, and that
   while option (4) was a really good choice, it might not be possible.
   We were left with whether a new DODAG or the existing base DODAG was
   the right answer.

5) we concluded that for self-organizing (no PCE) 6tisch networks, that
   per-pair L2 keys were very important due to the use of mac-layer IE
   to do schedule updates.   This has a code and energy impact on nodes
   in that they need to support one of the per-pair mechanisms listed on
   page 5 (section 3)[MLE,802.15.9,ohba-6tisch-security,piro-6tisch-secuirity].

   Not only is there a code space requirement, but there is also the need
   to have enough non-volatile storage to keep all of the (unique) keys to
   talk to each of one's neighbours.

   The upshot of this is that if you want to simplify the motes further,
   then having a PCE/JCE is an effective way as the motes need only maintain
   a single DTLS/CoAP/6top security association with the PCE, and the L2
   network key could be common across the entire network.

6) we did not finish discussion of section 3, and we will come back to
   that next week, and also talk about what is in the packets 10-13,
   and if we can cache anything that would reduce join traffic.

   we did dicuss intensitivity of join traffic, and how the JCE can
   control how many nodes (and in which order) they join.

7) I will provide an overview in the Oct. 24 group call, and I will
   revise the document slightly for next week.

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






_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security

--------------000207050404010109080507-- From nobody Sun Oct 26 14:20:29 2014 Return-Path: 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 A0A581A1A3A for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 14:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 6owCYOYuVSTT for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 14:20:24 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE8B1A19F1 for <6tisch-security@ietf.org>; Sun, 26 Oct 2014 14:20:23 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kx10so4161395pab.40 for <6tisch-security@ietf.org>; Sun, 26 Oct 2014 14:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=eqvZHwFcPCDATmqAwfFRl+2Z9Q21KdY1p7Cxz1ZKgl8=; b=dcvNWFvutJkYE9n62CAGfgTXi1eT+5tnGYIOTgCpL8UhZBeZ0de4PeYlFp73lSyLv1 REnKVPK2WtUIfbncoyidNKelMRrq4B1nOxJup6ACNe4KkvqV1wx1aZ9JYJLH3mB6mBQZ f9yW1f0xlCwoQHp01EUwZK8qxzQ7W0xtdxugXJs91lIRzke3Y55ZZL4s+uVTVr98obWn vQwo9dZ3N4tGE8MPVnQHqX2s5atAga0pW0Ujc4SM5Z0STO93//wT0c4wOoCy2/UNoYRP yqXmqVmCQ83AxiAp11N6T9qf09lLOwDRtHHrhTvM7FShrYNwvEvdOf+diNjrLhfjwIH1 vE+Q== X-Received: by 10.70.128.11 with SMTP id nk11mr19451998pdb.113.1414358423483; Sun, 26 Oct 2014 14:20:23 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.250.169 with HTTP; Sun, 26 Oct 2014 14:20:03 -0700 (PDT) In-Reply-To: <544D5408.7010304@berkeley.edu> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> <544D5408.7010304@berkeley.edu> From: Thomas Watteyne Date: Sun, 26 Oct 2014 14:20:03 -0700 X-Google-Sender-Auth: 6Ed31qQD39GsSvDr3X6hODXsVW4 Message-ID: To: Kris Pister Content-Type: multipart/alternative; boundary=001a11c3e0e66abd76050659fb1a Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/H8X80utM5Ip_Lw5jEVx1cMUl3WE Cc: Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 21:20:26 -0000 --001a11c3e0e66abd76050659fb1a Content-Type: text/plain; charset=UTF-8 Personally, I would greatly benefit from a detailed overview flows 10/11. I believe this would also help answer Kris' remarks. Michael, I believe it would be helpful to dedicate a significant portion of Tuesday's call on this. Thoughts? Thomas On Sun, Oct 26, 2014 at 1:05 PM, Kris Pister wrote: > Michael - I'm trying to get back up to speed on the security discussion, > so forgive a few > possibly out-of-date questions. > -------------------------------------------- > #1 Is this a correct statement of the start and end states? > > The mote starts with some authentication material, either > 1) a pre-shared join key > or > 2) a certificate > > The JCE starts with either > 1) the same pre-shared join key as the mote (possibly tied to the joining > mote > MAC ID, possibly unique, ...) > or > 2) a certificate > > The mote ends up with either > 1) a single network-wide L2 key for the production network > or > 2) multiple L2 keys for the production network, each associated with one > or more neighbors > -------------------------------------------- > #2 I'm a little confused on what's happening with flows in Figure 1. If I > remember > Jonathan's presentation correctly, I think that he was hoping to use > packets 2 and 3 > as a short cut to minimize the time and effort required for a DTLS PKI > based exchange. > If that's the case, then does it make sense to talk about a JCE-initiated > session in > packets 10 and 11? It seems like the joining mote has already said with > packet 2 > "hey, I speak short cut DTLS with secp256r1 - can you send me the JCE's > public key?" > or something like that. Yes? > > ksjp > > > On 10/21/2014 11:56 AM, Michael Richardson wrote: > > Michael Richardson wrote: > > base work today: - recap of plans for document (10minutes) > > > specific sections to review today: section 3. > > Attending today's meeting was: > - Thomas Watteyne > - Michael Richardson > - Kris Pister > - Mike Seewald > - Pat Kinney > - Subir Das > > 1) we got started 10 minutes late, and reviewed what the purpose of > the draft-richardson-6tisch-security-6top document was. > > There are two places for this text. > a) into the 6tisch-architecture (or possibly a new document, as per the WG) > b) into the 6tisch-6top document for the actual objects to adjust. > c) into some other documents that might wind up in ANIMA. > > 2) we worked on section 3. > we added some terms to the glossary and struggled with the > "network-wide" shared symmetric key that many other details cryptographic > key agreement protocols assume exists in order to authenticate exchanges. > > 3) we discussed whether or not we could use the 6top-over-15.4 Information > Elements (IE) to do security bootstrapping, and concluded that we can not, > as on the JOIN mac-key which authenticate that process would be well > known. > > 4) we discussed the question of end-to-end, JCE<->JoiningNode communication, > and the relative merits of the four possibilities outlined in section 3, > page 6. We agreed that option (1) [ipip] was a poor choice, and that > while option (4) was a really good choice, it might not be possible. > We were left with whether a new DODAG or the existing base DODAG was > the right answer. > > 5) we concluded that for self-organizing (no PCE) 6tisch networks, that > per-pair L2 keys were very important due to the use of mac-layer IE > to do schedule updates. This has a code and energy impact on nodes > in that they need to support one of the per-pair mechanisms listed on > page 5 (section 3)[MLE,802.15.9,ohba-6tisch-security,piro-6tisch-secuirity]. > > Not only is there a code space requirement, but there is also the need > to have enough non-volatile storage to keep all of the (unique) keys to > talk to each of one's neighbours. > > The upshot of this is that if you want to simplify the motes further, > then having a PCE/JCE is an effective way as the motes need only maintain > a single DTLS/CoAP/6top security association with the PCE, and the L2 > network key could be common across the entire network. > > 6) we did not finish discussion of section 3, and we will come back to > that next week, and also talk about what is in the packets 10-13, > and if we can cache anything that would reduce join traffic. > > we did dicuss intensitivity of join traffic, and how the JCE can > control how many nodes (and in which order) they join. > > 7) I will provide an overview in the Oct. 24 group call, and I will > revise the document slightly for next week. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > > _______________________________________________ > 6tisch-security mailing list6tisch-security@ietf.orghttps://www.ietf.org/mailman/listinfo/6tisch-security > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --001a11c3e0e66abd76050659fb1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Personally, I would greatly benefit from a detailed o= verview flows 10/11. I believe this would also help answer Kris' remark= s.

Michael,
I believe it would be he= lpful to dedicate a significant portion of Tuesday's call on this. Thou= ghts?

Thomas

On Sun, Oct 26, 2014 at 1:05 PM, Kris Piste= r <ksjp@berkeley.edu> wrote:
=20 =20 =20
Michael - I'm trying to get back up to speed on the security discussion, so forgive a few
possibly out-of-date questions.
--------------------------------------------
#1 Is this a correct statement of the start and end states?

The mote starts with some authentication material, either
1) a pre-shared join key
or
2) a certificate

The JCE starts with either
1) the same pre-shared join key as the mote (possibly tied to the joining mote
MAC ID, possibly unique, ...)
or
2) a certificate

The mote ends up with either
1) a single network-wide L2 key for the production network
or
2) multiple L2 keys for the production network, each associated with one or more neighbors
--------------------------------------------
#2 I'm a little confused on what's happening with flows in Figu= re 1.=C2=A0 If I remember
Jonathan's presentation correctly, I think that he was hoping to us= e packets 2 and 3
as a short cut to minimize the time and effort required for a DTLS PKI based exchange.
If that's the case, then does it make sense to talk about a JCE-initiated session in
packets 10 and 11?=C2=A0 It seems like the joining mote has already sai= d with packet 2
"hey, I speak short cut DTLS with secp256r1 - can you send me the JCE's public key?"
or something like that.=C2=A0 Yes?

ksjp


On 10/21/2014 11:56 AM, Michael Richardson wrote:
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > base work today: - recap of plans for document (10minutes)

    > specific sections to review today: section 3.

Attending today's meeting was:
- Thomas Watteyne
- Michael Richardson
- Kris Pister
- Mike Seewald
- Pat Kinney
- Subir Das

1) we got started 10 minutes late, and reviewed what the purpose of
   the draft-richardson-6tisch-security-6top document was.

   There are two places for this text.
   a) into the 6tisch-architecture (or possibly a new document, as per the =
WG)
   b) into the 6tisch-6top document for the actual objects to adjust.
   c) into some other documents that might wind up in ANIMA.

2) we worked on section 3.
   we added some terms to the glossary and struggled with the
   "network-wide" shared symmetric key that many other details cr=
yptographic
   key agreement protocols assume exists in order to authenticate exchanges=
.

3) we discussed whether or not we could use the 6top-over-15.4 Information
   Elements (IE) to do security bootstrapping, and concluded that we can no=
t,
   as on the JOIN mac-key which authenticate that process would be well
   known.

4) we discussed the question of end-to-end, JCE<->JoiningNode communi=
cation,
   and the relative merits of the four possibilities outlined in section 3,
   page 6.  We agreed that option (1) [ipip] was a poor choice, and that
   while option (4) was a really good choice, it might not be possible.
   We were left with whether a new DODAG or the existing base DODAG was
   the right answer.

5) we concluded that for self-organizing (no PCE) 6tisch networks, that
   per-pair L2 keys were very important due to the use of mac-layer IE
   to do schedule updates.   This has a code and energy impact on nodes
   in that they need to support one of the per-pair mechanisms listed on
   page 5 (section 3)[MLE,802.15.9,ohba-6tisch-security,piro-6tisch-secuiri=
ty].

   Not only is there a code space requirement, but there is also the need
   to have enough non-volatile storage to keep all of the (unique) keys to
   talk to each of one's neighbours.

   The upshot of this is that if you want to simplify the motes further,
   then having a PCE/JCE is an effective way as the motes need only maintai=
n
   a single DTLS/CoAP/6top security association with the PCE, and the L2
   network key could be common across the entire network.

6) we did not finish discussion of section 3, and we will come back to
   that next week, and also talk about what is in the packets 10-13,
   and if we can cache anything that would reduce join traffic.

   we did dicuss intensitivity of join traffic, and how the JCE can
   control how many nodes (and in which order) they join.

7) I will provide an overview in the Oct. 24 group call, and I will
   revise the document slightly for next week.

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






_______________________________________________
6tisch-security mailing list
6tisch-securi=
ty@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security


_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security


--001a11c3e0e66abd76050659fb1a-- From nobody Sun Oct 26 15:03:52 2014 Return-Path: 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 D2C091A1A17 for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 15:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 okBD0ZauOnoX for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 15:03:48 -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 F31651A19F9 for <6tisch-security@ietf.org>; Sun, 26 Oct 2014 15:03:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BDA0520012; Sun, 26 Oct 2014 18:04:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9252563A84; Sun, 26 Oct 2014 18:03:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7F95B63A82; Sun, 26 Oct 2014 18:03:46 -0400 (EDT) From: Michael Richardson To: Kris Pister In-Reply-To: <544D5408.7010304@berkeley.edu> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> <544D5408.7010304@berkeley.edu> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/M41V91R7-ncio4TS9d0X6StOq3w Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 22:03:50 -0000 --=-=-= Kris Pister wrote: > Michael - I'm trying to get back up to speed on the security > discussion, so forgive a few possibly out-of-date questions. > -------------------------------------------- > #1 Is this a correct statement of the start and end states? > The mote starts with some authentication material, either 1) a > pre-shared join key or 2) a certificate No. Neither. That's sort of the closer to the end state, but not really. The mote starts with a certificate from it's factory attesting to it's identity. The JCE starts with a certificate chain from the factory attesting to it's ownership of the mote. > The mote ends up with either 1) a single network-wide L2 key for the > production network or 2) multiple L2 keys for the production network, > each associated with one or more neighbors No, the mote winds up with a locally significant certificate or network-wide master key, and it uses those to derive (1) and/or (2) using one of MLE/802.15.9/piro/ohba documents. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVE1vwoCLcPvd0N1lAQKUMQf/V5lRg4BVgSGbjx7rHJOs6Zo+t3KjCjMU +kltE5lZjbHbDCACLvaniQ5P2HD4+AWrUOYW4V8m8ndRodz5IC1e7FnwtD6P7Hxe csWTkN1ucwg8GbW0mY5Ey2y6xg7pSjK4bVlc9swCZdrlcz9iltr06gmO0Keefv55 bSA86jNrAtDPql8SSy4Usr5DNdjqj8xnTL6mf/n+fEuOvGEpFVF1tI2OIVWOigzb 8GOJmDYhp4NlFycdnHUuW4u24nKr9WjO/XF4LARk9Srf4Xaa9diki3jyHIu7Xnoo Q16Wff448imCo8dfe/VvUpAHggynLXJERA3IQEl97Zh6hxXcIwwhtg== =XzQT -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 26 15:10:19 2014 Return-Path: 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 61B301A1AB3 for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 15:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 v3xoq2vfUHwV for <6tisch-security@ietfa.amsl.com>; Sun, 26 Oct 2014 15:09:58 -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 DACB21A1AC9 for <6tisch-security@ietf.org>; Sun, 26 Oct 2014 15:09:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 57F2B20012; Sun, 26 Oct 2014 18:11:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1B9F163A84; Sun, 26 Oct 2014 18:09:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 01A8F63A82; Sun, 26 Oct 2014 18:09:57 -0400 (EDT) From: Michael Richardson To: Thomas Watteyne In-Reply-To: References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> <544D5408.7010304@berkeley.edu> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/NWNRDsiNZL__0MTaXtcrmeYhI7s Cc: Kris Pister , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 22:10:09 -0000 --=-=-= Thomas Watteyne wrote: > Personally, I would greatly benefit from a detailed overview flows > 10/11. I believe this would also help answer Kris' remarks. > Michael, I believe it would be helpful to dedicate a significant > portion of Tuesday's call on this. Thoughts? Yes, let's do that. The required reading is: 1) draft-pritikin-bootstrapping-keyinfrastructures-00 2) https://mailarchive.ietf.org/arch/msg/6tisch-security/DT-K0_qd_wd-GmqB4YVqQtbhC6Q Suggested reading: 3) draft-richardson-6tisch-idevid-cert-00 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVE1xNICLcPvd0N1lAQJvFwf+P25TIHMYN1PtbL4Jvinrd5vEbt8VfNMg enJPaVP3hXRJiRBRCkEAIJ+VsEQg/pssQ4hUcfm7C4IJwV0DiWgWHHDA4UYxn47x osEPY/w5kMbncMbggU/y+FsJhi/3RHyb+mSu5ut0Xpm2aTQPo/MZhKB48fY+jEP4 nZ31+4X3C+W7kc1hCwQ5tr25KjkD8h2tMp7yCLHkNhnzpiTDTcFBAR64QjWFl/pf DKaJt1PxDvtQBGPW6hG15pF5704rXz+LrXBrHnCuc9b5L6kh23LU8Y/zLg9gVGFM VaIztwlc1zQqHDOi5QxevAi/zqzr6ul6BsCaI1p6fvfUHtaTGmc+EA== =Zd5q -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 27 08:26:52 2014 Return-Path: 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 0A3F81ACE33 for <6tisch-security@ietfa.amsl.com>; Mon, 27 Oct 2014 08:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 bYMzENOzV0ff for <6tisch-security@ietfa.amsl.com>; Mon, 27 Oct 2014 08:26:49 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8681ACE30 for <6tisch-security@ietf.org>; Mon, 27 Oct 2014 08:26:47 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id g10so5842780pdj.38 for <6tisch-security@ietf.org>; Mon, 27 Oct 2014 08:26:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KceO4tlg/DIfjY3c+USLXQcqWp97i2UWI/ZDFAOIY4A=; b=eb+kpLWi/kA5PmyK1Q0zoBblq+XiAACFgLJSYKFW6851i8v6mDai9chuJ0bXhMGBs3 PLg4UI0+YPRFMRadq28zJA3kOD2GlSl4Tom1cZ+4LpQZGpBb8eG5VwPgurON5D8QHy1m FgSo7O5vIYzgctL2JbyFUjuVgnVpOww2Xc+6RG47jl5GS6ACFQMgI11FnmAS0M6LI50E eSjI2W5B/z1lmySpO1eSh8L7ubKtWMeDss1qufrHC9w6bWC+fMUCEc+GpttOiAYdjEmY zra/6oeU6w/wfrz4Fx+SdPfBXErtnGr5ZZuJnv+ncegl0Xj5eyehoCuSG/F/V0uqL7vN 422w== X-Gm-Message-State: ALoCoQlgdo5y874Ycax6oy45LjgDXTUeunPDstg/apkeqdNhaeC89tAbJVb/yCzVifwSdvmbp0t4 X-Received: by 10.68.255.133 with SMTP id aq5mr18741703pbd.0.1414423607382; Mon, 27 Oct 2014 08:26:47 -0700 (PDT) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id ib8sm11270468pad.43.2014.10.27.08.26.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 08:26:46 -0700 (PDT) Message-ID: <544E6433.3080301@berkeley.edu> Date: Mon, 27 Oct 2014 08:26:43 -0700 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> <544D5408.7010304@berkeley.edu> <31737.1414361026@sandelman.ca> In-Reply-To: <31737.1414361026@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/TXZh7Wgt444YCbsCkK1ItoEcmTQ Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:26:51 -0000 Hmm. > > The mote starts with [...] a certificate > No. Neither. [...] The mote starts with a certificate My understanding is that you're excluding the use of a PSK. Why? I'm completely confused about the word "Neither" applied to the set that includes "certificate", followed by "The mote starts with a certificate". > > The mote ends up with either 1) a single network-wide L2 key for the > > production network or 2) multiple L2 keys for the production network, > No, the mote winds up with a locally significant certificate or network-wide > master key, and it uses those to derive (1) and/or (2) using > one of MLE/802.15.9/piro/ohba documents. It seems that the end state is (1) and/or (2), and that we must specify the complete mechanism to get there. ksjp On 10/26/2014 3:03 PM, Michael Richardson wrote: > Kris Pister wrote: > > Michael - I'm trying to get back up to speed on the security > > discussion, so forgive a few possibly out-of-date questions. > > -------------------------------------------- > > #1 Is this a correct statement of the start and end states? > > > The mote starts with some authentication material, either 1) a > > pre-shared join key or 2) a certificate > > No. Neither. That's sort of the closer to the end state, but not really. > > The mote starts with a certificate from it's factory attesting to it's > identity. The JCE starts with a certificate chain from the factory > attesting to it's ownership of the mote. > > > The mote ends up with either 1) a single network-wide L2 key for the > > production network or 2) multiple L2 keys for the production network, > > each associated with one or more neighbors > > No, the mote winds up with a locally significant certificate or network-wide > master key, and it uses those to derive (1) and/or (2) using > one of MLE/802.15.9/piro/ohba documents. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Oct 27 14:01:24 2014 Return-Path: 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 E61681AC424 for <6tisch-security@ietfa.amsl.com>; Mon, 27 Oct 2014 14:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 NJqA6hi_IgNg for <6tisch-security@ietfa.amsl.com>; Mon, 27 Oct 2014 14:01:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C469C1AD502 for <6tisch-security@ietf.org>; Mon, 27 Oct 2014 14:01:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 84956200A7; Mon, 27 Oct 2014 17:02:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 13DC463A84; Mon, 27 Oct 2014 17:01:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EFD5763A21; Mon, 27 Oct 2014 17:01:03 -0400 (EDT) From: Michael Richardson To: Kris Pister In-Reply-To: <544E6433.3080301@berkeley.edu> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> <544D5408.7010304@berkeley.edu> <31737.1414361026@sandelman.ca> <544E6433.3080301@berkeley.edu> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/x4DIpAKNSco8M_LiCF8Y2tqkEsM Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:01:07 -0000 --=-=-= Kris Pister wrote: >> > The mote starts with [...] a certificate No. Neither. [...] The >> mote starts with a certificate > My understanding is that you're excluding the use of a PSK. Why? 1) PSK is easy. PSK authenticated DTLS is defined, just use it rather than certificates, if you have an environment that can deal with it. 2) PSK fails a number of use cases and threats that many have said are important. > I'm completely confused about the word "Neither" applied to the set > that includes "certificate", followed by "The mote starts with a > certificate". The mote does not start with a locally significant/root certificate. It starts with a certificate from the vendor. >> > The mote ends up with either 1) a single network-wide L2 key for the >> > production network or 2) multiple L2 keys for the production >> network, No, the mote winds up with a locally significant certificate >> or > network-wide >> master key, and it uses those to derive (1) and/or (2) using one of >> MLE/802.15.9/piro/ohba documents. > It seems that the end state is (1) and/or (2), and that we must specify > the complete mechanism to get there. Yes, we have to decide how to specify the exact key derivation mechanism; but once the DTLS-secured 6top session is up we have the full expressive power of YANG in which to do it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVE6yj4CLcPvd0N1lAQIlkwf+O9W8NARlQKprLz9lc+5uPwjtZSeJ7R8u mYCUIwbioCyQgekSYy0h+mItjurVUOo0Dn7Y1gJkQpZwvTool9YjzBbSN4gvrUdv 79P2QvVIwLzPgjRzOcPlnpD8tQHKBaSUQv4bpIPntEO/8KorP9gqQk592s+dm6aq rMFHsGxQ/LvUMOfrQO96/gS1aOXNdj1mIO80IhKPmqfgFHwBQtGBEjGQs4Eo84IE 6jDXpLRETj8bGFfAcd7qPbvQETXUITW9TInDjLHpohvu4fh4b8iYi5wCoJ8tD8hy +z2KhjKlCurcbFYIgE4RU4w5akd0m2dmj7xpDaNekoygT2WdplX+fQ== =HlAW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 27 14:51:11 2014 Return-Path: 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 23B141A0099; Mon, 27 Oct 2014 14:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 pMiZWkBaS2ua; Mon, 27 Oct 2014 14:51:02 -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 E6EB01A000F; Mon, 27 Oct 2014 14:51:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C62F22016A; Mon, 27 Oct 2014 17:52:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3907D63A84; Mon, 27 Oct 2014 17:51:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1CD8363A21; Mon, 27 Oct 2014 17:51:01 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org, 6tisch@ietf.org In-Reply-To: References: 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/d2CN6qv6djJ45yQ2nSfrFVeRfdY Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-03: notification to ML? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:51:05 -0000 --=-=-= Thomas Watteyne wrote: > Michael, I see only know that you have rev'ed > draft-richardson-6tisch--security-6top. Apparently the system does not > CC the ML for individual submissions (normal?) Could you forward the > notification to 6tisch@ietf.org and 6tisch-security@ietf.org? Thanks, > Thomas Hi, I posted -03 to last night. (not sure how I got that double -- there) https://www.ietf.org/rfcdiff?url1=draft-richardson-6tisch--security-6top-02&difftype=--html&submit=Go%21&url2=draft-richardson-6tisch--security-6top-03 This contains the edits that we did last Tuesday. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVE6+RICLcPvd0N1lAQIVtgf/fmTV8jZugH7ooN8bgShkmZ8BEeCa2zNE AmMKGZR4+vG+qv+IaHY49hsfaydTENDcggg2KWnPAfU6NVAumm1EKeHrqgTIj2t6 hu1HSiMlaVNIh4BI3sLVd7NfRZ5kYkDM6nPl/7eC62EDc4iEkWR65nmpdD/+qVld OWh6vhGahJhp+DgIxS8N+vaSTt7m/B38FNcryuP52BK1FPsyMGL8ccastAJkVifu JYDXJ7TSyifxVX+FX9g7eGjkntWKcsn8UfVpQf46EjpxSRcgNretEOGYbyhRSNAG NjNeFrWNqVW3fFa1LIJ7RYgusdoMsniLqGrz5Je6mD9C30gkniajLw== =ScXE -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 27 20:08:05 2014 Return-Path: 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 F2AEE1A70E2 for <6tisch-security@ietfa.amsl.com>; Mon, 27 Oct 2014 20:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ldRmf0THz6ef for <6tisch-security@ietfa.amsl.com>; Mon, 27 Oct 2014 20:07:55 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3EA1A1B4A for <6tisch-security@ietf.org>; Mon, 27 Oct 2014 20:07:53 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id r10so6884435pdi.30 for <6tisch-security@ietf.org>; Mon, 27 Oct 2014 20:07:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zC0oIWIrN3/hFT6i3KGSjFdGj90OufMitmqp//tokXk=; b=ZaqqTF/3US7zbYGAipOesr3lOhIqurgaREQ4TvnkzmTZjz+2pj5H5Kc7aWtrg6HrQz O/JM7R+FX2MYlB6r8IBATItbn2TPQ3c1CiE8OXth/80gsEAmqaznD7WeN0Rw7UDCLZaq nq5PZGGaE5lsxVayzySdQe/gLd4zYKH+zSoG5baCTfsKFaWi0Pmf917Pwo196CaCqFtG LQZsU0yc35OPBiEpu7bxvnEedG5jYke5Itg4qbH+XBcXa/vCYUeo0G+4qPc4+6eiUcdq wQ9j3ohhAq+ZwuRt0jgMts9q1DENiT4AX8mAmiTQgnNMIY8RP3W+yRauO/RVPIa6ScW0 LX6A== X-Gm-Message-State: ALoCoQkaLofFI9HAM9Knm7pgYXwR5oQOpSO2Cbg8EQDhYKe1zW6nGwktXc5vNqtaNrATisOuLRdM X-Received: by 10.70.92.68 with SMTP id ck4mr667105pdb.28.1414465673214; Mon, 27 Oct 2014 20:07:53 -0700 (PDT) Received: from [10.0.0.3] ([98.210.76.194]) by mx.google.com with ESMTPSA id k11sm193022pbq.0.2014.10.27.20.07.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 20:07:52 -0700 (PDT) Message-ID: <544F0873.8070006@berkeley.edu> Date: Mon, 27 Oct 2014 20:07:31 -0700 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> <544D5408.7010304@berkeley.edu> <31737.1414361026@sandelman.ca> <544E6433.3080301@berkeley.edu> <325.1414443663@sandelman.ca> In-Reply-To: <325.1414443663@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/SUD4wl5yKk-2TjfC1pxHnyH1yAk Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 03:08:01 -0000 OK, this seems like the beginnings of convergence. I agree with you that PSK fails a number of use cases and threats. I'm very much in favor of being able to use certificates to solve those problems. I'm also in favor of allowing less-demanding applications to use PSK, because as you say, PSK is easy. I do think that its important to define a security framework that is both flexible and complete. In that vein, and trying to be cognizant of your terminology, I'll try again. The mote starts with some authentication material, either 1) a pre-shared join key or 2) a vendor certificate The JCE starts with either 1) the same PSK as the mote (possibly tied to the joining mote MAC ID, possibly unique, ...) or 2) a vendor certificate, and the public keys of one or more trust anchors The mote ends up with either 1) a network wide master key or 2) a locally significant certificate from which it derives either 1) a single network-wide L2 key for the production network or 2) multiple L2 keys for the production network, each associated with one or more neighbors ksjp On 10/27/2014 2:01 PM, Michael Richardson wrote: > Kris Pister wrote: > >> > The mote starts with [...] a certificate No. Neither. [...] The > >> mote starts with a certificate > > > My understanding is that you're excluding the use of a PSK. Why? > > 1) PSK is easy. PSK authenticated DTLS is defined, just use it rather > than certificates, if you have an environment that can deal with it. > > 2) PSK fails a number of use cases and threats that many have said are > important. > > > I'm completely confused about the word "Neither" applied to the set > > that includes "certificate", followed by "The mote starts with a > > certificate". > > The mote does not start with a locally significant/root certificate. > It starts with a certificate from the vendor. > > >> > The mote ends up with either 1) a single network-wide L2 key for the > >> > production network or 2) multiple L2 keys for the production > >> network, No, the mote winds up with a locally significant certificate > >> or > > network-wide > >> master key, and it uses those to derive (1) and/or (2) using one of > >> MLE/802.15.9/piro/ohba documents. > > > It seems that the end state is (1) and/or (2), and that we must specify > > the complete mechanism to get there. > > Yes, we have to decide how to specify the exact key derivation mechanism; but > once the DTLS-secured 6top session is up we have the full expressive power of > YANG in which to do it. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Tue Oct 28 07:37:27 2014 Return-Path: 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 328BD1A899B for <6tisch-security@ietfa.amsl.com>; Tue, 28 Oct 2014 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] 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 lTrAdVPPoDFB for <6tisch-security@ietfa.amsl.com>; Tue, 28 Oct 2014 07:37:24 -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 3B0471A8980 for <6tisch-security@ietf.org>; Tue, 28 Oct 2014 07:37:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C69B20028; Tue, 28 Oct 2014 10:38:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7522763A84; Tue, 28 Oct 2014 10:37:23 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5D53E63A21; Tue, 28 Oct 2014 10:37:23 -0400 (EDT) From: Michael Richardson To: Kris Pister In-Reply-To: <544F0873.8070006@berkeley.edu> References: <12229.1413553891@sandelman.ca> <17957.1413736225@sandelman.ca> <6219.1413900830@sandelman.ca> <32378.1413917788@sandelman.ca> <544D5408.7010304@berkeley.edu> <31737.1414361026@sandelman.ca> <544E6433.3080301@berkeley.edu> <325.1414443663@sandelman.ca> <544F0873.8070006@berkeley.edu> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ST5ZzAU3aMHZphCWdce_gLij-Bk Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] draft-richardson-6tisch--security-6top-02 questions (Re: two 6TiSCH security working calls) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 14:37:25 -0000 --=-=-= Kris Pister wrote: > The mote starts with some authentication material, either > 1) a pre-shared join key > or > 2) a vendor certificate I'm gonna be picky here again, because I don't want to confuse anyone. Let's not call it a "join key", because that sounds like the L2 well-known JOIN KEY. Let's call it a "symmetric authenticator" > The JCE starts with either > 1) the same PSK as the mote (possibly tied to the joining mote MAC ID, > possibly unique, ...) I'm pretty sure that it needs to be completely unique per node MAC ID. (Over in 6tisch, we agreed to say "node" rather than "mote"...) > 2) a vendor certificate, and the public keys of one or more trust anchors I don't like saying "trust anchors" here because for many this will imply talking to Versign or Komodo or something. I think you mean: one or more supply chain certificate chains in the trusted store. > The mote ends up with either > 1) a network wide master key > or > 2) a locally significant certificate > from which it derives either > 1) a single network-wide L2 key for the production network > or > 2) multiple L2 keys for the production network, each associated with one or > more neighbors Exactly. Let's talk today about giving better terminology to these things, and making the expectations of this clear. What you have just done is clearly articulated the architectural requirements... we need to tighten up the terminology, even if we have to make up abstract names like: Bob and Phil or Orange and Purple. We agreed to talk today about how the 6top DTLS session will be authenticated when dealing with certificates; for me this has become core ANIMA stuff, although I'm not sure the ANIMA people yet agree. ps: it seems I'm coming to gogo6live Nov.19/20 in Bay area, after IETF91; got a couple of days free beforehand. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVE+qI4CLcPvd0N1lAQJMYAgAs45ck+CTvuyndfDyLTkh9qfiNGR0Nl/K ruTRmvnhVTeK0/hIn2ymTDXYmwSgvdlNqXX3eX0Affo0mxoRSfC8yhCQlsJFtQ+Q FUQrWfbsxw4VnwfQ/OarPRB0Lx9xf3cqGvfiZ2Fw0lAt7md94A72QH3oQXugvS2F 3/7hultrbfdJX6Z4LSWl5v3DP6egwQT5TRAxHZvB/DrMGZ7FYg/EQKITlFDxBoTW S6cHVCoV/b/e10O4eywqnkGK2SrwQ17i1F7YLiciNoT0AbeeQs3weFNK18R+jjqj hi8xvfiekkGieIyiTDV6VCI1YQvVVb+e9DZgMCFwVB6pmvxKwqdMCg== =ivxf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 28 08:00:18 2014 Return-Path: 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 49E511A8A52 for <6tisch-security@ietfa.amsl.com>; Tue, 28 Oct 2014 08:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.999, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01, WEIRD_PORT=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 gmDPn_LC2Jac for <6tisch-security@ietfa.amsl.com>; Tue, 28 Oct 2014 08:00:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3E31A8A4D for <6tisch-security@ietf.org>; Tue, 28 Oct 2014 08:00:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 946C320028 for <6tisch-security@ietf.org>; Tue, 28 Oct 2014 11:01:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8388B63A84; Tue, 28 Oct 2014 11:00:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6DD1863A21 for <6tisch-security@ietf.org>; Tue, 28 Oct 2014 11:00:12 -0400 (EDT) From: Michael Richardson To: 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/CXOkfd7sYhsBCGlt95M1zH5jW0s Subject: [6tisch-security] webex for 2014-10-28 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:00:17 -0000 --=-=-= Meeting number: 645 146 419 Meeting password: timeslot Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 etherpad for meeting: http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt please note that google/browser-using-google-data might bitch about it being a phising site, it is likely a false positive, and I've let ietf-action know about it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVE+vfICLcPvd0N1lAQJ7qAgAjCy5p+oK4YEG9TXNEcw5JbsENAmIZw1p TNe+/4oBkTAKpikjFfZjeW0qsWxaUjRzlZGMU718DC3exSaPRe7iWMM52ZK46pZn CEaX3Ur5LSUO8kuRvu8J3TeiJ+zqsDoKqeF0sj5SMH8w+G/ylfzz7Ie98ORgtkOW EqxgLuFbaaK6bhexPNDIjiDzZgps1ldlS7fxQbNLr/hunSGz0dKxwa3mEV0LONpO AYvjLdVPkjazkSRkyuALn2B+hVwFQXx3JH6qj7quiSVbk58wPfP0bm37YJX5ARU0 s9UrFmJQFOx3zDx8eyVpLnObZgYywzm07Yb+8p9FvPasMXZ7UV9BUQ== =8Lpx -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 30 16:31:40 2014 Return-Path: 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 D4F981A89B4 for <6tisch-security@ietfa.amsl.com>; Thu, 30 Oct 2014 16:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ix1ZuZTaCsma for <6tisch-security@ietfa.amsl.com>; Thu, 30 Oct 2014 16:31:32 -0700 (PDT) Received: from p02c12o144.mxlogic.net (p02c12o144.mxlogic.net [208.65.145.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CF01A89AF for <6tisch-security@ietf.org>; Thu, 30 Oct 2014 16:31:31 -0700 (PDT) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o144.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id 25ac2545.0.98556.00-383.272028.p02c12o144.mxlogic.net (envelope-from ); Thu, 30 Oct 2014 17:31:31 -0600 (MDT) X-MXL-Hash: 5452ca5375e6e5a9-7a66de377ad589e1e89f2567aa1064b8656cd1ca Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 1C29F740B5 for <6tisch-security@ietf.org>; Thu, 30 Oct 2014 16:31:28 -0700 (PDT) From: Jonathan Simon Content-Type: multipart/alternative; boundary="Apple-Mail=_5C55FF18-7CC2-44BE-8AEA-75F01E784510" Message-Id: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> Date: Thu, 30 Oct 2014 16:30:53 -0700 To: 6tisch-security@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=a78k9CiF c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=2_pVTAb8kL] X-AnalysisOut: [ojitF3TSoA:9 a=pILNOxqGKmIA:10 a=B6niZy2Ubl4A:10 a=w5YT6rc] X-AnalysisOut: [CX-EqlKhl:21 a=_W_S_7VecoQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014103020); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/MXK_hMsl_5XChlILOxgraZBXDCw Subject: [6tisch-security] X.509 Cert sizes and joining flows 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:31:37 -0000 --Apple-Mail=_5C55FF18-7CC2-44BE-8AEA-75F01E784510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I voiced my concern a while back about certificate exchanges making = joining really slow: = http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.html= There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert = is going to be 5x worse. One reason the certs are big is that there is a lot of stuff we don't = need, or may not need, or could compress a la 6lo. Version: could be elided? Serial number: Maybe this is the EUI of the device (elidable). Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to = cover the full expanded X.509 fields. Issuer: may be compressible? Validity: 26 bytes - do we need to be able to revoke certs, or could = this be handled on an app level. Subject: can be empty SubjectPublicKeyInfo: contains an algorithm definition (which can be = elided if we only use one) or compressed (if we support a few), and the = public key (32 bytes) IssuerUniqueIdentifier: optional SubjectUniqueIdentifier: optional Extensions: optional, but if we don't include a subject we might want to = support subjectAltName, again probably in compressed form. SignatureAlgorithm: can be elided if we only use one or compressed if we = support a few Other fields? Point is, I think we can get this to fit into 2 packets and I think that = should be our target unless there=92s a really a compelling reason to = include fields. --=20 Jonathan Simon --Apple-Mail=_5C55FF18-7CC2-44BE-8AEA-75F01E784510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I = voiced my concern a while back about certificate exchanges making = joining really slow:


There I = assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is going = to be 5x worse.

One reason the certs are big is that there is a lot = of stuff we don't need, or may not need, or could compress a la = 6lo.

Version: could be elided?
Serial = number: Maybe this is the EUI of the device = (elidable).
Signature:  ~80 bytes for secp256r1 (128-bits = protection).  Needs to cover the full expanded X.509 = fields.
Issuer: may be compressible?
Validity: 26 = bytes - do we need to be able to revoke certs, or could this be handled = on an app level.
Subject: can be = empty
SubjectPublicKeyInfo: contains an algorithm definition = (which can be elided if we only use one) or compressed (if we support a = few), and the public key (32 bytes)
IssuerUniqueIdentifier: = optional
SubjectUniqueIdentifier: = optional
Extensions: optional, but if we don't include a = subject we might want to support subjectAltName, again probably in = compressed form.
SignatureAlgorithm: can be elided if we = only use one or compressed if we support a few
Other = fields?

Point is, I think we can get this to = fit into 2 packets and I think that should be our target unless there=92s = a really a compelling reason to include = fields.

-- 
Jonathan = Simon
= --Apple-Mail=_5C55FF18-7CC2-44BE-8AEA-75F01E784510-- From nobody Fri Oct 31 03:17:32 2014 Return-Path: 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 3F4381A000C for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 03:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 dfY-e60HbB7k for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 03:17:27 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6F11A19E2 for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 03:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10804; q=dns/txt; s=iport; t=1414750646; x=1415960246; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=wqdKJttJqEjRoBxW9TnGl3AAkK/oJrHaoy7cMnbsGLI=; b=PNXeUFomHXUSEMs9Kre6uPCxjkkB8dGKuYGJ3sZ8yw81BJ5LkUByHZSd xN1EeTBfZx36ieuZ7frTRS464Uze8fz5astS8tQ9UjvK8pQwqz3+oYT6B b19b7qWKDQT6FzN16Swrs+7tk5+2mUMq1M8iyoxZIFBxzFvFO0bdLPCLo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFADphU1StJV2Y/2dsb2JhbABcgkhGVFgEzROHSwKBGxYBAQEBAX2EAgEBAQQtXAIBCA4DBAEBCx0HMhQJCAIEARIIAYg4DclXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF41BAYJ9AQEeNwGDLYEeBZIVoiuBfiCBWmwBgQUJFwIggQMBAQE X-IronPort-AV: E=Sophos; i="5.07,294,1413244800"; d="scan'208,217"; a="92056566" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 31 Oct 2014 10:17:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9VAHOVc011894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 10:17:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 05:17:24 -0500 From: "Pascal Thubert (pthubert)" To: Jonathan Simon , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] X.509 Cert sizes and joining flows Thread-Index: AQHP9JmqNnL2J4HaAEi68gvd+J9W85xJ/gQA Date: Fri, 31 Oct 2014 10:17:24 +0000 Deferred-Delivery: Fri, 31 Oct 2014 10:17:00 +0000 Message-ID: References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> In-Reply-To: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.15] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A2B5F4xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/TQjH02OCoQlM6E-L_2SAlHY8Mp0 Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 10:17:30 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A2B5F4xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jonathan: Are you suggesting that we define a "6LoWPAN compression" for a certificate= ? Cheers, Pascal From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Jonathan Simon Sent: vendredi 31 octobre 2014 00:31 To: 6tisch-security@ietf.org Subject: [6tisch-security] X.509 Cert sizes and joining flows I voiced my concern a while back about certificate exchanges making joining= really slow: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.html There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is = going to be 5x worse. One reason the certs are big is that there is a lot of stuff we don't need,= or may not need, or could compress a la 6lo. Version: could be elided? Serial number: Maybe this is the EUI of the device (elidable). Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to cover = the full expanded X.509 fields. Issuer: may be compressible? Validity: 26 bytes - do we need to be able to revoke certs, or could this b= e handled on an app level. Subject: can be empty SubjectPublicKeyInfo: contains an algorithm definition (which can be elided= if we only use one) or compressed (if we support a few), and the public ke= y (32 bytes) IssuerUniqueIdentifier: optional SubjectUniqueIdentifier: optional Extensions: optional, but if we don't include a subject we might want to su= pport subjectAltName, again probably in compressed form. SignatureAlgorithm: can be elided if we only use one or compressed if we su= pport a few Other fields? Point is, I think we can get this to fit into 2 packets and I think that sh= ould be our target unless there's a really a compelling reason to include f= ields. -- Jonathan Simon --_000_E045AECD98228444A58C61C200AE1BD848A2B5F4xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jonathan:

 <= /p>

Are you suggesting that w= e define a “6LoWPAN compression” for a certificate?<= /span>

 <= /p>

Cheers,<= /o:p>

 

Pascal

 <= /p>

From: 6tisch-s= ecurity [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Jonathan Simon
Sent: vendredi 31 octobre 2014 00:31
To: 6tisch-security@ietf.org
Subject: [6tisch-security] X.509 Cert sizes and joining flows

 

I voiced my concern a while back about certificate excha= nges making joining really slow:

 

 

There I assumed a 300-byte compressed cert. Obviously, a= 1500-byte cert is going to be 5x worse.

 

One reason the certs are big is that there is a lot of s= tuff we don't need, or may not need, or could compress a la 6lo.=

 

Version: could be elided?

Serial number: Maybe this is the EUI of the device (elid= able).

Signature:  ~80 bytes for secp256r1 (128-bits prote= ction).  Needs to cover the full expanded X.509 fields.

Issuer: may be compressible?

Validity: 26 bytes - do we need to be able to revoke cer= ts, or could this be handled on an app level.

Subject: can be empty

SubjectPublicKeyInfo: contains an algorithm definition (= which can be elided if we only use one) or compressed (if we support a few)= , and the public key (32 bytes)

IssuerUniqueIdentifier: optional

SubjectUniqueIdentifier: optional

Extensions: optional, but if we don't include a subject = we might want to support subjectAltName, again probably in compressed = form.

SignatureAlgorithm: can be elided if we only use on= e or compressed if we support a few

Other fields?

 

Point is, I think we can get this to fit into 2 packets = and I think that should be our target unless there’s a really a compe= lling reason to include fields.

 

-- 
Jonathan Simon

--_000_E045AECD98228444A58C61C200AE1BD848A2B5F4xmbrcdx01ciscoc_-- From nobody Fri Oct 31 08:48:55 2014 Return-Path: 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 F005C1A9049 for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 08:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 eW8N0dlmGoJQ for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 08:48:50 -0700 (PDT) Received: from p02c12o142.mxlogic.net (p02c12o142.mxlogic.net [208.65.145.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDD11A014F for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 08:48:50 -0700 (PDT) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o142.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id 26fa3545.2acabb244940.53309.00-574.153767.p02c12o142.mxlogic.net (envelope-from ); Fri, 31 Oct 2014 09:48:50 -0600 (MDT) X-MXL-Hash: 5453af6209ae088f-2d371ee2da806970be9356e6be058fc92ce79bc6 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o142.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id c5fa3545.0.53257.00-294.153608.p02c12o142.mxlogic.net (envelope-from ); Fri, 31 Oct 2014 09:48:45 -0600 (MDT) X-MXL-Hash: 5453af5d2b032aeb-c3c8d39817bc3108bb849109770b362c30978439 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 96039740AC; Fri, 31 Oct 2014 08:48:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_385B4968-FA8E-44BA-A5CF-8F4968DC4AD5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jonathan Simon In-Reply-To: Date: Fri, 31 Oct 2014 08:48:04 -0700 Message-Id: References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=XbqdzeJ5 c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=UmfJlIhswHRCPjHwG5kA:9 a=YEleoESzjb2TjAte:21 a=Wmbp] X-AnalysisOut: [59OleJqckwgr:21 a=pILNOxqGKmIA:10 a=B6niZy2Ubl4A:10 a=SyYM] X-AnalysisOut: [xH9GAAAA:8 a=Fx7SCTmYqjmZAMpA:21 a=yqrnmnE3ArreMP8-:21 a=e] X-AnalysisOut: [oFYCR1RNfyCtiYL:21 a=_W_S_7VecoQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014103104); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/5O1VuTF6sEpgYmoHtrjMDbZj4tw Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:48:53 -0000 --Apple-Mail=_385B4968-FA8E-44BA-A5CF-8F4968DC4AD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Pascal - Yes - I don=92t know where the effort belongs though. I think we need a = standard way of compressing an X.509 cert with the goal of fitting it in = under 200 bytes. Maybe this compressed cert is only used at joining in = 6TiSCH, or maybe border routers can compress/decompress along with the = 6LoWPAN header so we can use it end-to-end. =97=20 Jonathan=20 On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) = wrote: > Hello Jonathan: > =20 > Are you suggesting that we define a =936LoWPAN compression=94 for a = certificate? > =20 > Cheers, > =20 > Pascal > =20 > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On = Behalf Of Jonathan Simon > Sent: vendredi 31 octobre 2014 00:31 > To: 6tisch-security@ietf.org > Subject: [6tisch-security] X.509 Cert sizes and joining flows > =20 > I voiced my concern a while back about certificate exchanges making = joining really slow: > =20 > = http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.html= > =20 > There I assumed a 300-byte compressed cert. Obviously, a 1500-byte = cert is going to be 5x worse. > =20 > One reason the certs are big is that there is a lot of stuff we don't = need, or may not need, or could compress a la 6lo. > =20 > Version: could be elided? > Serial number: Maybe this is the EUI of the device (elidable). > Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to = cover the full expanded X.509 fields. > Issuer: may be compressible? > Validity: 26 bytes - do we need to be able to revoke certs, or could = this be handled on an app level. > Subject: can be empty > SubjectPublicKeyInfo: contains an algorithm definition (which can be = elided if we only use one) or compressed (if we support a few), and the = public key (32 bytes) > IssuerUniqueIdentifier: optional > SubjectUniqueIdentifier: optional > Extensions: optional, but if we don't include a subject we might want = to support subjectAltName, again probably in compressed form. > SignatureAlgorithm: can be elided if we only use one or compressed if = we support a few > Other fields? > =20 > Point is, I think we can get this to fit into 2 packets and I think = that should be our target unless there=92s a really a compelling reason = to include fields. > =20 > --=20 > Jonathan Simon --Apple-Mail=_385B4968-FA8E-44BA-A5CF-8F4968DC4AD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Pascal = -

Yes - I don=92t know where the effort belongs = though.  I think we need a standard way of compressing an X.509 = cert with the goal of fitting it in under 200 bytes. Maybe this = compressed cert is only used at joining in 6TiSCH, or maybe border = routers can compress/decompress along with the 6LoWPAN header so we can = use it end-to-end.

=97 

Jonathan 

On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) = <pthubert@cisco.com> = wrote:

Hello Jonathan:
 
Are you suggesting that = we define a =936LoWPAN compression=94 for a = certificate?
 
Cheers,
 
Pascal
 
From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Jonathan = Simon
Sent: vendredi 31 octobre 2014 = 00:31
To: 6tisch-security@ietf.org
Subject: [6tisch-security] X.509 = Cert sizes and joining flows
 
I voiced my = concern a while back about certificate exchanges making joining really = slow:
 
 
There I assumed a 300-byte = compressed cert. Obviously, a 1500-byte cert is going to be 5x = worse.
 
One reason the certs are big = is that there is a lot of stuff we don't need, or may not need, or could = compress a la 6lo.
 
Version: could be = elided?
Serial number: Maybe this is = the EUI of the device (elidable).
Signature:  ~80 bytes for secp256r1 (128-bits protection). =  Needs to cover the full expanded X.509 = fields.
Issuer: may be = compressible?
Validity: 26 = bytes - do we need to be able to revoke certs, or could this be handled = on an app level.
Subject: can = be empty
SubjectPublicKeyInfo: = contains an algorithm definition (which can be elided if we only use = one) or compressed (if we support a few), and the public key (32 = bytes)
IssuerUniqueIdentifier: = optional
SubjectUniqueIdentifier: = optional
Extensions: optional, but if = we don't include a subject we might want to support subjectAltName, = again probably in compressed = form.
SignatureAlgorithm: can = be elided if we only use one or compressed if we support a = few
Other = fields?
 
Point is, I think we can get = this to fit into 2 packets and I think that should be our target unless = there=92s a really a compelling reason to include = fields.
 
-- 
Jonathan = Simon

= --Apple-Mail=_385B4968-FA8E-44BA-A5CF-8F4968DC4AD5-- From nobody Fri Oct 31 09:26:46 2014 Return-Path: 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 E4A921A01BA; Fri, 31 Oct 2014 09:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, 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 Zcf4DKJmoktI; Fri, 31 Oct 2014 09:26:41 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161481A0060; Fri, 31 Oct 2014 09:26:41 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rp18so1603529iec.37 for ; Fri, 31 Oct 2014 09:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=41T0uNYJgSl/quJrIYH/tOG1+rn+jX+dgerFQHhrefI=; b=0dM67Re4gkxPTdKLQCEplgQ2f2j9fQJRcYkAggVdub8D0qznx0IHhh0ijUuS2gniYf Jfi+kDwz9DwAic8TZyn6xt0wTSPc9OSE1hXmol5k40ihWecG0WCIE+1pVWdKIO+/WdQZ nXqarg1WSnVqoWFeR4ftSzLqvT4d/CtwQBVwd+WJ+5XOC4l9fKc52vYC/z8LxQlAZto8 u6Btj1UqVtPCwwUfNQvr8kPUBYZ/5wohO66GeO3evk3vqsBi5x5gHnE5+7sz4zcGTEaO xqzstNemZLGlGMpfwK1Wk33JS5Tk8ZMyUJAyhKOHkCg0PnYCqELsg2SvGF5yXndddWDN /y/A== X-Received: by 10.107.128.146 with SMTP id k18mr4084454ioi.69.1414772800455; Fri, 31 Oct 2014 09:26:40 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id q8sm5421974ioe.1.2014.10.31.09.26.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Oct 2014 09:26:40 -0700 (PDT) Message-ID: <5453B837.5040305@gmail.com> Date: Fri, 31 Oct 2014 12:26:31 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jonathan Simon , "Pascal Thubert (pthubert)" References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080607040209020002050206" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/xESfGw23KGszaKuEnOtYUCYB-Zg Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 16:26:44 -0000 This is a multi-part message in MIME format. --------------080607040209020002050206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Jonathan: The join protocol includes (1) authentication; (2) authorization; (3) configuration steps. Without hands tied behind the back with protocol design, I anticipate the main communication overhead of the join protocol to be with the configuration step (#3) and *not* with the underlying authenticated key agreement scheme (#1). Here, configuration relates both to security manager to joining node info and vice-verse. See also item #a of my May 20, 2014 email -- _which is still outstanding BTW._ Que - Would you like to take this one on? {as first step, what about providing a rough number, say, 1500 bytes [fill in correct number here]}. Some brief feedback on certificate sizes: a) certificates should definitely have policy fields, including key validity period. b) certificate compression is of course possible, including that of certificate issuer (whether the latter would be prudent remains to be seen). c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message). d) there is no absolute need to use X509 certs, which would add considerable freedom to cut down overhead. I estimate one can implement the authentication scheme (#1) with one or two 802.15.4e frames in each protocol flow (assuming cert chains of length one). Email of May 20, 2014 with outstanding issues: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html a) Packet sizes: get more info on packet sizes configuration parms, as w/HART uses. Note RS: during call, Tom Phinney suggested contacting Wally Bratt from HART Comm. Foundation for this). Note RS: Shouldn't, e.g., Dust Networks have info on packet sizes/structure?; ISA SP100.11a metrics would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points here? b) Device Ids: With industrial control, network manager would look up "tag name" device in pre-configured database. Details on tag name syntax, how assigned, and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney could point at tag name syntax and lifecycle aspects here? On 10/31/2014 11:48 AM, Jonathan Simon wrote: > Pascal - > > Yes - I don’t know where the effort belongs though. I think we need a > standard way of compressing an X.509 cert with the goal of fitting it > in under 200 bytes. Maybe this compressed cert is only used at joining > in 6TiSCH, or maybe border routers can compress/decompress along with > the 6LoWPAN header so we can use it end-to-end. > > — > > Jonathan > > On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) > > wrote: > >> Hello Jonathan: >> Are you suggesting that we define a “6LoWPAN compression” for a >> certificate? >> Cheers, >> Pascal >> *From:*6tisch-security [mailto:6tisch-security-bounces@ietf.org]*On >> Behalf Of*Jonathan Simon >> *Sent:*vendredi 31 octobre 2014 00:31 >> *To:*6tisch-security@ietf.org >> *Subject:*[6tisch-security] X.509 Cert sizes and joining flows >> I voiced my concern a while back about certificate exchanges making >> joining really slow: >> http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.html >> >> There I assumed a 300-byte compressed cert. Obviously, a 1500-byte >> cert is going to be 5x worse. >> One reason the certs are big is that there is a lot of stuff we don't >> need, or may not need, or could compress a la 6lo. >> Version: could be elided? >> Serial number: Maybe this is the EUI of the device (elidable). >> Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to >> cover the full expanded X.509 fields. >> Issuer: may be compressible? >> Validity: 26 bytes - do we need to be able to revoke certs, or could >> this be handled on an app level. >> Subject: can be empty >> SubjectPublicKeyInfo: contains an algorithm definition (which can be >> elided if we only use one) or compressed (if we support a few), and >> the public key (32 bytes) >> IssuerUniqueIdentifier: optional >> SubjectUniqueIdentifier: optional >> Extensions: optional, but if we don't include a subject we might want >> to support subjectAltName, again probably in compressed form. >> SignatureAlgorithm: can be elided if we only use one or compressed if >> we support a few >> Other fields? >> Point is, I think we can get this to fit into 2 packets and I think >> that should be our target unless there’s a really a compelling reason >> to include fields. >> -- >> Jonathan Simon > > > > This body part will be downloaded on demand. -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080607040209020002050206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Jonathan:

The join protocol includes (1) authentication; (2) authorization; (3) configuration steps.
Without hands tied behind the back with protocol design, I anticipate the main communication overhead of the join protocol to be with the configuration step (#3) and *not* with the underlying authenticated key agreement scheme (#1). Here, configuration relates both to security manager to joining node info and vice-verse.

See also item #a of my May 20, 2014 email -- which is still outstanding BTW.
Que - Would you like to take this one on? {as first step, what about providing a rough number, say, 1500 bytes [fill in correct number here]}.

Some brief feedback on certificate sizes:
a) certificates should definitely have policy fields, including key validity period.
b) certificate compression is of course possible, including that of certificate issuer (whether the latter would be prudent remains to be seen).
c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message).
d) there is no absolute need to use X509 certs, which would add considerable freedom to cut down overhead.

I estimate one can implement the authentication scheme (#1) with one or two 802.15.4e frames in each protocol flow (assuming cert chains of length one).

Email of May 20, 2014 with outstanding issues:
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
a) Packet sizes: 
get more info on packet sizes configuration parms, as w/HART uses. Note RS: during call, Tom Phinney suggested contacting Wally Bratt from HART Comm. Foundation for this).  Note RS: Shouldn't, e.g., Dust Networks have info on packet sizes/structure?; ISA SP100.11a metrics would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points here?
b) Device Ids:
With industrial control, network manager would look up "tag name" device in pre-configured database. Details on tag name syntax, how assigned, and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney could point at tag name syntax and lifecycle aspects here?

On 10/31/2014 11:48 AM, Jonathan Simon wrote:
Pascal -

Yes - I don’t know where the effort belongs though.  I think we need a standard way of compressing an X.509 cert with the goal of fitting it in under 200 bytes. Maybe this compressed cert is only used at joining in 6TiSCH, or maybe border routers can compress/decompress along with the 6LoWPAN header so we can use it end-to-end.

— 

Jonathan 

On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Hello Jonathan:
 
Are you suggesting that we define a “6LoWPAN compression” for a certificate?
 
Cheers,
 
Pascal
 
From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Jonathan Simon
Sent: vendredi 31 octobre 2014 00:31
To: 6tisch-security@ietf.org
Subject: [6tisch-security] X.509 Cert sizes and joining flows
 
I voiced my concern a while back about certificate exchanges making joining really slow:
 
 
There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is going to be 5x worse.
 
One reason the certs are big is that there is a lot of stuff we don't need, or may not need, or could compress a la 6lo.
 
Version: could be elided?
Serial number: Maybe this is the EUI of the device (elidable).
Signature:  ~80 bytes for secp256r1 (128-bits protection).  Needs to cover the full expanded X.509 fields.
Issuer: may be compressible?
Validity: 26 bytes - do we need to be able to revoke certs, or could this be handled on an app level.
Subject: can be empty
SubjectPublicKeyInfo: contains an algorithm definition (which can be elided if we only use one) or compressed (if we support a few), and the public key (32 bytes)
IssuerUniqueIdentifier: optional
SubjectUniqueIdentifier: optional
Extensions: optional, but if we don't include a subject we might want to support subjectAltName, again probably in compressed form.
SignatureAlgorithm: can be elided if we only use one or compressed if we support a few
Other fields?
 
Point is, I think we can get this to fit into 2 packets and I think that should be our target unless there’s a really a compelling reason to include fields.
 
-- 
Jonathan Simon



This body part will be downloaded on demand.


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------080607040209020002050206-- From nobody Fri Oct 31 11:33:14 2014 Return-Path: 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 103521A0217 for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XhKjVSFaDA9r for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 11:33:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7541A01AA for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 11:33:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D596E203B2 for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 14:34:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D9189637EA; Fri, 31 Oct 2014 14:33:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BB7B163740 for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 14:33:08 -0400 (EDT) From: Michael Richardson To: "6tisch-security\@ietf.org" <6tisch-security@ietf.org> In-Reply-To: References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/jOWs7ZV8AvEZ3KJJryDXSqFgx5s Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:33:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jonathan Simon wrote: > Yes - I don=E2=80=99t know where the effort belongs though. I think = we need a > standard way of compressing an X.509 cert with the goal of fitting it > in under 200 bytes. Maybe this compressed cert is only used at joining > in 6TiSCH, or maybe border routers can compress/decompress along with > the 6LoWPAN header so we can use it end-to-end. There is no reason the certificate compression needs to be in *6lo* it can be part of DTLS. A 256 EC public key takes 88 bytes raw. Running gzip on that file expands it to 114 bytes :-) (not surprising, it ought be rather random, gzip header overhead) Turning that into a self-signed certificate with a CN=3D12347624: Certificate: Data: Version: 1 (0x0) Serial Number: 86:52:cb:df:30:2c:88:c1 Signature Algorithm: ecdsa-with-SHA1 Issuer: CN=3D12347624 Validity Not Before: Oct 31 18:28:09 2014 GMT Not After : Nov 30 18:28:09 2014 GMT Subject: CN=3D12347624 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey EC Public Key: pub: 04:4c:24:f9:e5:8d:ee:e5:b9:da:23:51:d2:fb:35: 83:4d:71:69:57:ca:78:7e:3c:f9:a7:cc:ed:b5:e3: 12:cd:d7:a1:49:9d:7f:0c:b4:47:07:6e:6b:d1:b6: 5d:26:90:b5:d9:b5:af:18:d3:42:8d:fc:11:93:58: 37:03:be:c9:cc ASN1 OID: secp256k1 Signature Algorithm: ecdsa-with-SHA1 30:44:02:20:15:a6:93:d1:9f:81:65:53:34:d7:9c:28:81:73: d6:39:c6:3d:e1:ed:65:31:67:9c:5a:16:6c:12:ae:f6:09:6f: 02:20:42:af:3a:07:94:15:cd:c9:f0:9a:b2:65:7c:5e:c6:55: 61:ee:35:e3:4f:39:53:29:2c:5e:31:15:8b:40:ec:42 428 bytes in base64 format, 275 bytes binary, gzip'ed 274 bytes! =2D----BEGIN CERTIFICATE----- MIIBDzCBuAIJAIZSy98wLIjBMAkGByqGSM49BAEwEzERMA8GA1UEAxMIMTIzNDc2 MjQwHhcNMTQxMDMxMTgyODA5WhcNMTQxMTMwMTgyODA5WjATMREwDwYDVQQDEwgx MjM0NzYyNDBWMBAGByqGSM49AgEGBSuBBAAKA0IABEwk+eWN7uW52iNR0vs1g01x aVfKeH48+afM7bXjEs3XoUmdfwy0Rwdua9G2XSaQtdm1rxjTQo38EZNYNwO+ycww CQYHKoZIzj0EAQNHADBEAiAVppPRn4FlUzTXnCiBc9Y5xj3h7WUxZ5xaFmwSrvYJ bwIgQq86B5QVzcnwmrJlfF7GVWHuNeNPOVMpLF4xFYtA7EI=3D =2D----END CERTIFICATE----- I don't think it matters what protocol one uses for join; it won't get a lot smaller than this. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFPV4YCLcPvd0N1lAQLsQAf9F8q0GfiQJ+lniCIyAG/ctv0CtOGG3tIL JYIw2tZXzUjdBuIOfu8bqqBR6UIlN97DDjXCe7NHRMnA6DkbWTpd7363F49F518D w1C9Py4QVOeASF7C7lM5mdZVtrNA9WygaGVUt2itmcv5CYl6tvt8hX/ufxYZD/cK jLH9AyTBqvnG2ksXopUmOAOlQKp9PoV6af6gQK6lhObUsk6o23SXm6snkcYh440O EuHgmLQXy9LfQy0K7q+OTtL+suH7Kpe0vssw1wu6zT7P0/Fh9ko9aR+syiG+daiV 6P4eNaJj3UXvqNow8AH6u4ANGNadgLhn7Wc/8MDLAL1Hjrwdybrpbw== =EWIT -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 31 11:39:05 2014 Return-Path: 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 6CA041A19F2 for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 11:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01, WEIRD_PORT=0.001] autolearn=ham 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 6uuIIVKSDWLm for <6tisch-security@ietfa.amsl.com>; Fri, 31 Oct 2014 11:38:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75401A01A8 for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 11:38:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0C73B203B2 for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 14:40:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1803D637EA; Fri, 31 Oct 2014 14:38:50 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F200E63740 for <6tisch-security@ietf.org>; Fri, 31 Oct 2014 14:38:50 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: <4227.1414508412@sandelman.ca> References: <4227.1414508412@sandelman.ca> 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/8WW9PGShhWanQ85oF5QrItKHmhQ Subject: [6tisch-security] webex for 2014-11-04 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:38:55 -0000 --=-=-= At the 2014-10-28 call, we decided that we would in fact continue on 2014-11-04. It will be the same time; 8am Pacific, 11am Eastern (Standard). Which will be 16:00 UTC after the time change this weekend. Michael Richardson wrote: > Meeting number: 645 146 419 Meeting password: timeslot Audio > connection: 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 > etherpad for meeting: > http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt > please note that google/browser-using-google-data might complain about it > being a phising site, it is likely a false positive, and I've let > ietf-action know about it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFPXOICLcPvd0N1lAQI3kQgAmtCth6/BtH1fmg4Xof699XOIezr92qwo ApkHZmKD1Mrf/UCAlU0bMq9HimdBHkfwCjIW90iY+jVZXhla6YIOrmAk+ce/36ip P8xIzUpKQNQCXdxYQgBWhlL0I7G7Gigwz8ga6d24b+EX0jdRYpxcxTjkcZrAWNAm /7TmzWvrYsNWQUTgOfJV2yOUulnAVf8eAqDyf1HOJdGwUZ1DIhTHyJToS52X+Jvc 8OvIZZ0v+xzE+uqHV/BUisPjv7OodMUcqSNSFVIenRjXqHQ0+EInCcTUseQM8fWf Qk6a5aO40YE3VHevaZA3BnmsalJbdN59T/roHRwtTYa4awWODdDz/A== =6zSw -----END PGP SIGNATURE----- --=-=-=--