From nobody Fri Oct 3 08:02:01 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA21C1A0162 for ; Fri, 3 Oct 2014 08:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, LOTS_OF_MONEY=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 EvvdlChTfLwf for ; Fri, 3 Oct 2014 08:01:54 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAD51A014B for ; Fri, 3 Oct 2014 08:01:54 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id a13so2606690igq.4 for ; Fri, 03 Oct 2014 08:01:53 -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=GqhmFHqbSdoHofKTiRnQtAmgggoCg3wPER1n2swzsPE=; b=UbkaUawQfNnZlbrqo4GdZizC/0m497qMmHx122kLh0+a4LKSCAA6F6g5W9rT3dxdyb phhGUlPgTGjnTAqsMEsfiV/iGvs1e4hV+m9/RsN0iaNSMTId6bpSPKP2XpqRCWY0z/yJ q5B2dMcZsGHQc/HjeD9M7sTx/GHsy6UIs47a077UwJiPGqEEdpTtpryhDP6Us1IigCmn TinXXidUMdvHDIml+A5esdvUYfrPsU8yVr/Jlv/YH/Kj5bT4AlQs5P62Y8keQu/9zPTd v9R2S///ZMBEORxTnaoSXwbWAXWW5IP5zFC15NJh0Ojhfu4+sKqzHQIMCQqKVXe1v3U0 XMCw== X-Received: by 10.50.66.36 with SMTP id c4mr15254376igt.48.1412348513408; Fri, 03 Oct 2014 08:01:53 -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 ro6sm1950015igb.3.2014.10.03.08.01.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Oct 2014 08:01:53 -0700 (PDT) Message-ID: <542EBA5D.5090105@gmail.com> Date: Fri, 03 Oct 2014 11:01:49 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Gellert, Dorothy" References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> In-Reply-To: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> X-Forwarded-Message-Id: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> Content-Type: multipart/alternative; boundary="------------090006000000020705050108" Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/pHq_e2vqfGIB-QSxmYGqgWrnUxY Cc: "dtls-iot@ietf.org" Subject: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:01:59 -0000 This is a multi-part message in MIME format. --------------090006000000020705050108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Dorothy: Apologies for responding late to this (I was away last week and only slowly catching up on email). I have gone through all the email regarding multicast security since Thu Sept 18, 2014, but saw lots of posturing, but not too much technical analysis of the problem space. Main questions: a) Is source authentication vs. group authentication technically feasible within typical use case constraints? What are these constraints? Note: it is hard to find the codification of these constraints. {In other groups, one often uses ballparks of human perception time latencies of 250ms.} b) Is source authentication vs. group authentication desirable? Note: it seems this is certainly so for control messaging and perhaps for others (I have only seen the light presence sensor and broadcast of "switch on" example by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), although Michael St. Johns gave a more futuristic "flock of drones" example (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). The effect of messaging includes a state change on the recipient. I would expect some analysis of what to do in case of diagnosis (e.g., to find source of problem in lighting system or, in the case of drones, to figure out why that $2m drone suddenly crashed...). c) Is source authentication expensive? Note: the usual "certificates are expensive" argument has been touted by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html). The discussion I have seen focuses on static groups and "light bulb scenarios". This makes me wonder about this from a system perspective. Further questions: d) What happens if group membership changes? Note: group membership changes should trigger a security event and an update of group keys (with some trade-off in granularity vs. security policy invariants). This was indirectly alluded to by Michael St. Johns (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html). e) How are group keys distributed in the first place? Note: there has not been too much discussion on the mailing list as to how one sets up a secure channel in the first place, esp. in heterogeneous settings (e.g., not just a single vendor solution -- Philips Lighting only, say). There are possibilities to implement homogeneous trust domain solutions, such as HIMMO, but these (a) still require a secure channel for distribution of key shares; (b) are not designed with heterogeneous trust domain (multi-vendor operations) in mind. I think it would behoove the group to have a clarify these questions, via a technical discussion, rather than political posturing. Some related discussion prior to the IETF-90 meeting in Toronto (the "Tyranny of the lightswitch" email series triggered by Michael St. Johns) seems to suggest that the answer to question #a above may very well be affirmative (message #322 is by STMicro): http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html Most posturing seems to be motivated by a desire to use symmetric-key only constructs. This may be fine, but does not necessarily address system level questions and the question how one can build systems that draw from multiple vendors this way. Best regards, Rene -------- Forwarded Message -------- Subject: [Dtls-iot] DTLS multicast security Date: Thu, 18 Sep 2014 13:41:06 -0700 From: Dorothy Gellert To: dtls-iot@ietf.org Dear WG, Last week our AD and the WG chairs, myself and Zach, met to discuss the progress of the DTLS multicast security Work Item. it seems as though we have reach an impasse with regards to the issues raised on the mailing list with multicast security and DTLS. If this is the consensus of the WG we can progress the WG without this Work item and move forward with the other 2 work items, the dtls profile and practical issues around the DTLS handshake. I’d like to request feedback from the WG on this plan. Thanks, Dorothy _______________________________________________ dtls-iot mailing list dtls-iot@ietf.org https://www.ietf.org/mailman/listinfo/dtls-iot --------------090006000000020705050108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Dorothy:

Apologies for responding late to this (I was away last week and only slowly catching up on email).

I have gone through all the email regarding multicast security since Thu Sept 18, 2014, but saw lots of posturing, but not too much technical analysis of the problem space.

Main questions:
a) Is source authentication vs. group authentication technically feasible within typical use case constraints? What are these constraints?
Note: it is hard to find the codification of these constraints. {In other groups, one often uses ballparks of human perception time latencies of 250ms.}
b) Is source authentication vs. group authentication desirable?
Note: it seems this is certainly so for control messaging and perhaps for others (I have only seen the light presence sensor and broadcast of "switch on" example by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), although Michael St. Johns gave a more futuristic "flock of drones" example (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). The effect of messaging includes a state change on the recipient. I would expect some analysis of what to do in case of diagnosis (e.g., to find source of problem in lighting system or, in the case of drones, to figure out why that $2m drone suddenly crashed...).
c) Is source authentication expensive?
Note: the usual "certificates are expensive" argument has been touted by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html).

The discussion I have seen focuses on static groups and "light bulb scenarios". This makes me wonder about this from a system perspective.

Further questions:
d) What happens if group membership changes?
Note: group membership changes should trigger a security event and an update of group keys (with some trade-off in granularity vs. security policy invariants). This was indirectly alluded to by Michael St. Johns (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html).
e) How are group keys distributed in the first place?
Note: there has not been too much discussion on the mailing list as to how one sets up a secure channel in the first place, esp. in heterogeneous settings (e.g., not just a single vendor solution -- Philips Lighting only, say). There are possibilities to implement homogeneous trust domain solutions, such as HIMMO, but these (a) still require a secure channel for distribution of key shares; (b) are not designed with heterogeneous trust domain (multi-vendor operations) in mind.

I think it would behoove the group to have a clarify these questions, via a technical discussion, rather than political posturing.

Some related discussion prior to the IETF-90 meeting in Toronto (the "Tyranny of the lightswitch" email series triggered by Michael St. Johns) seems to suggest that the answer to question #a above may very well be affirmative (message #322 is by STMicro):
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html

Most posturing seems to be motivated by a desire to use symmetric-key only constructs. This may be fine, but does not necessarily address system level questions and the question how one can build systems that draw from multiple vendors this way.

Best regards, Rene

-------- Forwarded Message --------
Subject: [Dtls-iot] DTLS multicast security
Date: Thu, 18 Sep 2014 13:41:06 -0700
From: Dorothy Gellert <dorothy.gellert@gmail.com>
To: dtls-iot@ietf.org 


Dear WG,

Last week our AD and the WG chairs, myself and Zach, met to discuss the progress of the DTLS multicast security Work Item. 
it seems as though we have reach an impasse with regards to the issues raised on the mailing list with multicast security and DTLS.     

If this is the consensus of the WG  we can progress the WG without this Work item and move forward with the other 2 work items, the dtls profile and practical issues around the DTLS handshake.   

I’d like to request feedback from the WG on this plan.

Thanks, 
Dorothy 





_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot


--------------090006000000020705050108-- From nobody Fri Oct 3 09:28:07 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9781A03F9 for ; Fri, 3 Oct 2014 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 w9cG-rg4LRGD for ; Fri, 3 Oct 2014 09:27:59 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7697F1A03A4 for ; Fri, 3 Oct 2014 09:27:59 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i17so1266102qcy.2 for ; Fri, 03 Oct 2014 09:27:58 -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 :content-transfer-encoding; bh=K99JEO4X5ROaDW9XIXTcMussNvYnabnpAwa+8GErh54=; b=YIbNhWpZuXEtztlVInCLCxL5HMnyhFTysOtrSBEXXBKctXH63t3tT2ykLgVq4OhJce XXIE0zRJHO9UP2HJYpc/4fln8GRfEi3vSiTp50eKTynY/sf6v1WbIhxj1PY+7bBwIgNU vO2ch7VtGp5lKOej10yRn9PpZEqx2F7CxYBtFgFLC3f7E3YVFvINj1LEB2pyTaKdVpmT afSf+ctCKrArrouHkB8scJTvjPYNgqgXLLUU7lx3f++nonWo9rGWLQ/I2FAu+6ow/Hdn h5KmSgSooQRSrnu9/VDdU9xJdu5SpGelc49lQUqQqGNLRx7OaEyu0wkhSyYqDbefUT07 ozJg== X-Gm-Message-State: ALoCoQlsB1ANVO3JM5B3u9Mhxq4IjgyEPKECY/4toZq1YrKExkkgUxkeRVgMLDi7DeIYlPIxw7FP X-Received: by 10.224.115.139 with SMTP id i11mr7746287qaq.86.1412353678678; Fri, 03 Oct 2014 09:27:58 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:dd:bc45:b86d:ec25:aec3? ([2601:a:2a00:dd:bc45:b86d:ec25:aec3]) by mx.google.com with ESMTPSA id n78sm6061894qgd.41.2014.10.03.09.27.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Oct 2014 09:27:58 -0700 (PDT) Message-ID: <542ECE96.8030306@nthpermutation.com> Date: Fri, 03 Oct 2014 12:28:06 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <542EBA5D.5090105@gmail.com> In-Reply-To: <542EBA5D.5090105@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/PMSAelU0wfsuJeNpkjd1sVUxnyw Subject: Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:28:01 -0000 On 10/3/2014 11:01 AM, Rene Struik wrote: > although Michael St. Johns gave a more futuristic "flock of drones" > example > (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). The > effect of messaging includes a state change on the recipient. I would > expect some analysis of what to do in case of diagnosis (e.g., to find > source of problem in lighting system or, in the case of drones, to > figure out why that $2m drone suddenly crashed...). I was actually thinking more about something like a group of $300-$1000 quad copters. There are a lot of interesting YouTube videos about the emerging capabilities of flocking protocols. I haven't looked at the control protocols they're using, but I would expect they use some form of emergent behavior based on local knowledge to do collision avoidance and group travel. Mike From nobody Fri Oct 3 11:25:29 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC9A1A8884 for ; Fri, 3 Oct 2014 11:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, LOTS_OF_MONEY=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 PGz_i7YNA_kn for ; Fri, 3 Oct 2014 11:25:25 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA131A8759 for ; Fri, 3 Oct 2014 11:25:24 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id va2so1272877obc.25 for ; Fri, 03 Oct 2014 11:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pUWuaqTo2T7iWlAFHGs7l1D8YQ8pEAjfumKmXbvkffM=; b=ix1gbkdU/N5/PIV3wf5vvDUHXtrhR+mWixvupO/D6VC+ISmkZXlJklP6+YKmYOMxLk KY8CmPn3zr5qiFnxlwkqhS/A1euKoRv7/NMffkFb2z5oPxVO5zZAGUYFLzE85jgHnwZa GNJIdRqZBFwjvJA3kSW9aC5jUfEVAxpejZLVL0ekGgZ1Y3h4fJ+P4JdJS01jQT8Hx/fk ESAg7jQV8i2J5NHLlWx7ts9Utx6nQwLkxbaIX2y2N0dLQ3qUDvEgDkL6nYE8mCdNOeuY rY7qMvsbqqu2/3dl7NGe+1Ki1c8HRwNg5NyIcoj7uk9/xw4LaZ9SlPGN5QPrgu8fRRUZ 1V2A== X-Received: by 10.182.104.104 with SMTP id gd8mr8789496obb.17.1412360723281; Fri, 03 Oct 2014 11:25:23 -0700 (PDT) Received: from [192.168.1.205] (c-50-174-103-180.hsd1.ca.comcast.net. [50.174.103.180]) by mx.google.com with ESMTPSA id h1sm4755034obw.21.2014.10.03.11.25.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 11:25:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_377746CE-CB5E-4123-9ADB-2314E58C9866" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dorothy Gellert In-Reply-To: <542EBA5D.5090105@gmail.com> Date: Fri, 3 Oct 2014 11:25:13 -0700 Message-Id: References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <542EBA5D.5090105@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/60YVtDlUOC6pztRWfDT0p-d1vd4 Cc: "Gellert, Dorothy" , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 18:25:28 -0000 --Apple-Mail=_377746CE-CB5E-4123-9ADB-2314E58C9866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Rene, Thanks for your comments. When I read through your questions it seems = what you referring to in terms of system perspective is something along = the lines of Best Practices section that would address the questions you pose, such as diagnosis and group = membership. Key distribution was decided at the BoF to be out of band, = but can be described in a Best Practices section or document.=20 So far we have generated rough consensus around coap application based = group use cases that require confidentiality only. This is our problem = statement we agreed we needed at the last IETF meeting.=20 I also believe we have made the case that theses groups are =93small=94 = such that they can be enforced by the protocol. We have a lighting use case and desire for another use case. We need = more discussion around that.=20 Also from my discussions with my co -chair and AD, a discussion around = cipher suites should be considered, given TLS 1.3 has specified AEAD = cipher suites.=20 Can you get behind this way forward for the next meeting? Thanks, Dorothy In light of the=20 On Oct 3, 2014, at 8:01 AM, Rene Struik wrote: > Hi Dorothy: >=20 > Apologies for responding late to this (I was away last week and only = slowly catching up on email). >=20 > I have gone through all the email regarding multicast security since = Thu Sept 18, 2014, but saw lots of posturing, but not too much technical = analysis of the problem space. >=20 > Main questions: > a) Is source authentication vs. group authentication technically = feasible within typical use case constraints? What are these = constraints? > Note: it is hard to find the codification of these constraints. {In = other groups, one often uses ballparks of human perception time = latencies of 250ms.} > b) Is source authentication vs. group authentication desirable? > Note: it seems this is certainly so for control messaging and perhaps = for others (I have only seen the light presence sensor and broadcast of = "switch on" example by Sandeep Kumar = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), = although Michael St. Johns gave a more futuristic "flock of drones" = example = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). = The effect of messaging includes a state change on the recipient. I = would expect some analysis of what to do in case of diagnosis (e.g., to = find source of problem in lighting system or, in the case of drones, to = figure out why that $2m drone suddenly crashed...).=20 > c) Is source authentication expensive? > Note: the usual "certificates are expensive" argument has been touted = by Sandeep Kumar = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html). >=20 > The discussion I have seen focuses on static groups and "light bulb = scenarios". This makes me wonder about this from a system perspective. >=20 > Further questions: > d) What happens if group membership changes? > Note: group membership changes should trigger a security event and an = update of group keys (with some trade-off in granularity vs. security = policy invariants). This was indirectly alluded to by Michael St. Johns = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html). > e) How are group keys distributed in the first place? > Note: there has not been too much discussion on the mailing list as to = how one sets up a secure channel in the first place, esp. in = heterogeneous settings (e.g., not just a single vendor solution -- = Philips Lighting only, say). There are possibilities to implement = homogeneous trust domain solutions, such as HIMMO, but these (a) still = require a secure channel for distribution of key shares; (b) are not = designed with heterogeneous trust domain (multi-vendor operations) in = mind. >=20 > I think it would behoove the group to have a clarify these questions, = via a technical discussion, rather than political posturing. >=20 > Some related discussion prior to the IETF-90 meeting in Toronto (the = "Tyranny of the lightswitch" email series triggered by Michael St. = Johns) seems to suggest that the answer to question #a above may very = well be affirmative (message #322 is by STMicro): > http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html > http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html >=20 > Most posturing seems to be motivated by a desire to use symmetric-key = only constructs. This may be fine, but does not necessarily address = system level questions and the question how one can build systems that = draw from multiple vendors this way. >=20 > Best regards, Rene >=20 > -------- Forwarded Message -------- > Subject: [Dtls-iot] DTLS multicast security > Date: Thu, 18 Sep 2014 13:41:06 -0700 > From: Dorothy Gellert > To: dtls-iot@ietf.org >=20 > Dear WG, >=20 > Last week our AD and the WG chairs, myself and Zach, met to discuss = the progress of the DTLS multicast security Work Item.=20 > it seems as though we have reach an impasse with regards to the issues = raised on the mailing list with multicast security and DTLS. =20 >=20 > If this is the consensus of the WG we can progress the WG without = this Work item and move forward with the other 2 work items, the dtls = profile and practical issues around the DTLS handshake. =20 >=20 > I=92d like to request feedback from the WG on this plan. >=20 > Thanks,=20 > Dorothy=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot --Apple-Mail=_377746CE-CB5E-4123-9ADB-2314E58C9866 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Rene,

Thanks for your comments.   When I read = through your questions it seems what you referring to  in terms of = system perspective is something along the lines of Best Practices = section that
would address the questions you pose, such as = diagnosis and group membership.   Key distribution was decided at = the BoF to be out of band, but can be described in a Best Practices = section or document. 

So far we have = generated rough consensus around coap application based group use cases = that require confidentiality only.   This is our problem statement = we agreed we needed at the last IETF meeting. 
I also = believe we have made the case that theses groups are =93small=94 such = that they can be enforced by the protocol.

We = have a lighting use case and desire for another use case.  We need = more discussion around that. 
Also from my discussions = with my co -chair and AD, a discussion around cipher suites should be = considered, given TLS 1.3  has specified AEAD cipher = suites. 

Can you get behind this way = forward for the next = meeting?

Thanks,
Dorothy

=



In light of = the 
On Oct 3, 2014, at 8:01 AM, Rene Struik <rstruik.ext@gmail.com> = wrote:

=20 =20
Hi Dorothy:

Apologies for responding late to this (I was away last week and only slowly catching up on email).

I have gone through all the email regarding multicast security since Thu Sept 18, 2014, but saw lots of posturing, but not too much technical analysis of the problem space.

Main questions:
a) Is source authentication vs. group authentication technically feasible within typical use case constraints? What are these constraints?
Note: it is hard to find the codification of these constraints. {In other groups, one often uses ballparks of human perception time latencies of 250ms.}
b) Is source authentication vs. group authentication desirable?
Note: it seems this is certainly so for control messaging and perhaps for others (I have only seen the light presence sensor and broadcast of "switch on" example by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html= ), although Michael St. Johns gave a more futuristic "flock of drones" example (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html= )). The effect of messaging includes a state change on the recipient. I would expect some analysis of what to do in case of diagnosis (e.g., to find source of problem in lighting system or, in the case of drones, to figure out why that $2m drone suddenly crashed...).
c) Is source authentication expensive?
Note: the usual "certificates are expensive" argument has been touted by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html= ).

The discussion I have seen focuses on static groups and "light bulb scenarios". This makes me wonder about this from a system perspective.

Further questions:
d) What happens if group membership changes?
Note: group membership changes should trigger a security event and an update of group keys (with some trade-off in granularity vs. security policy invariants). This was indirectly alluded to by Michael St. Johns (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html= ).
e) How are group keys distributed in the first place?
Note: there has not been too much discussion on the mailing list as to how one sets up a secure channel in the first place, esp. in heterogeneous settings (e.g., not just a single vendor solution -- Philips Lighting only, say). There are possibilities to implement homogeneous trust domain solutions, such as HIMMO, but these (a) still require a secure channel for distribution of key shares; (b) are not designed with heterogeneous trust domain (multi-vendor operations) in mind.

I think it would behoove the group to have a clarify these questions, via a technical discussion, rather than political posturing.

Some related discussion prior to the IETF-90 meeting in Toronto (the "Tyranny of the lightswitch" email series triggered by Michael St. Johns) seems to suggest that the answer to question #a above may very well be affirmative (message #322 is by STMicro):
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html=
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html=

Most posturing seems to be motivated by a desire to use symmetric-key only constructs. This may be fine, but does not necessarily address system level questions and the question how one can build systems that draw from multiple vendors this way.

Best regards, Rene

-------- Forwarded Message --------
Subject: [Dtls-iot] DTLS multicast security
Date: Thu, 18 Sep 2014 13:41:06 -0700
From: Dorothy Gellert <dorothy.gellert@gmail.com>= ;
To: = dtls-iot@ietf.org 


Dear WG,

Last week our AD and the WG chairs, myself and Zach, met to discuss the =
progress of the DTLS multicast security Work Item.=20
it seems as though we have reach an impasse with regards to the issues =
raised on the mailing list with multicast security and DTLS.    =20

If this is the consensus of the WG  we can progress the WG without this =
Work item and move forward with the other 2 work items, the dtls profile =
and practical issues around the DTLS handshake.  =20

I=92d like to request feedback from the WG on this plan.

Thanks,=20
Dorothy=20





_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/dtls-iot


_______________________________________________
dtls-iot mailing = list
dtls-iot@ietf.org
https://www.iet= f.org/mailman/listinfo/dtls-iot

= --Apple-Mail=_377746CE-CB5E-4123-9ADB-2314E58C9866-- From nobody Fri Oct 3 11:53:17 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9331A1BC2 for ; Fri, 3 Oct 2014 11:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, LOTS_OF_MONEY=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 cPXtkDyozEjY for ; Fri, 3 Oct 2014 11:53:10 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFAF1A6FBB for ; Fri, 3 Oct 2014 11:53:10 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id hn18so3485946igb.9 for ; Fri, 03 Oct 2014 11:53:10 -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=clf7hxq03vfVlGaOiV9hnF6CcX0xHuVdkxpBtQMzeSo=; b=zRTPq/fb8AeouiN7KIy8lWur+Nvi4/anZOKB9GABFbhBWmmYRiWypS2WPcjd9hPaos fGc+VlGfbkqEz1PklNVPqKowJWIdSpVt7l/nBER3hxmGmt6SAm+9aRl/WegJck40Yd48 5FzPUwhIz4VGj2gshZbt5ncJEPfVJ6Ku0wd58B8SC4aFHSLkgWqFzeTISdIBew8AhRv5 Gh0QN2jvmppU8qp/5KjYhI0emPmuxDieMF5NFru2Gd6QOhqLtAdyl5ZcAI2oSJdJGalr jY64o9p3YAkGqzwTctbS6j3kvH7n4yQWT9Us25F7QTQz1KMYAxSxD09Gc6Ua3B9EiWN8 Iv4A== X-Received: by 10.50.122.101 with SMTP id lr5mr384788igb.43.1412362390151; Fri, 03 Oct 2014 11:53:10 -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 ga10sm2444138igd.0.2014.10.03.11.53.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Oct 2014 11:53:09 -0700 (PDT) Message-ID: <542EF092.3060708@gmail.com> Date: Fri, 03 Oct 2014 14:53:06 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Dorothy Gellert References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <542EBA5D.5090105@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080908050103010702010100" Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/8DcGhabcDfuFmko-7AepzqyW6FQ Cc: "Gellert, Dorothy" , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 18:53:15 -0000 This is a multi-part message in MIME format. --------------080908050103010702010100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Dorothy: Most of the posturing seems to have been triggered not so much by technical arguments as to merits of source authentication vs. group authentication, but by some parties simply not wishing to risk having to implement public key functionality. My email suggests that this posturing may be short-sighted and seemingly incompatible with the ultimate reason to even do standardization: facilitating deployments of systems with components from multiple vendors. In the end, one should be interested in having tools to build secure systems, not in Pyrrhus victories. I know that some people opted for option "A" on the email list last week, but those preferences seemed to lack technical justification (anything else was just moved, again, to another group -- ACE?). As such, I find this approach a poor man's justification the IETF unworthy. I think bringing technical merit discussion back on the table makes sense. We can roll up our sleeves and do some technical work or make this into a voting machinery (which I think IETF portends not to be). Even if one just wishes to stick with poor man's solutions, it would be good to finally get technical requirements on the table (e.g., re time latency, etc.), which has all been severely lacking so far. Just ask yourself: why does it take 8 weeks of absolute silence since IETF-90 to suddenly get a flurry of posturing emails when multicast is mentioned by you in an email, with no technical arguments exchanged to justify option A? This may be a way to partition a problem, but has little to do with looking for a long-term viable technical mechanism for multicast. BTW - here are my perspectives on the questions I posed: a) Is source authentication vs. group authentication technically feasible within typical use case constraints? *YES, feasible**(without even the need to sign every message, so hybrid symmetric/public key approach possible). See also some emails of July 2014.* What are these constraints?*Let us stick with 250 ms time latency, failing further concise problem statements.* b) Is source authentication vs. group authentication desirable? *Yes, for control messages. Just implement accross the board, to preclude feature creep of group authentication (which will happen - IETF cannot prevent people misusing constructs, so simply do not provide them).* c) Is source authentication expensive? *No. See technical data points, Hannes Tschofenig's ARM speaker organized webcast, certs in consumer space virtually for free, etc.* d) What happens if group membership changes? *Change of group membership requires a point to point secure channel update, thereby source authentication.* e) How are group keys distributed in the first place? *Heterogeneous deployments, also in the lighting arena, require a heterogeneous lifecycle model, which is scalable with public-key technology. If one needs this anyway (why standardize otherwise, instead of having companies all do their own thing?), one could use the primitive also for source authentication in multi-cast setting.* Rene On 10/3/2014 2:25 PM, Dorothy Gellert wrote: > Hi Rene, > > Thanks for your comments. When I read through your questions it > seems what you referring to in terms of system perspective is > something along the lines of Best Practices section that > would address the questions you pose, such as diagnosis and group > membership. Key distribution was decided at the BoF to be out of > band, but can be described in a Best Practices section or document. > > So far we have generated rough consensus around coap application based > group use cases that require confidentiality only. This is our > problem statement we agreed we needed at the last IETF meeting. > I also believe we have made the case that theses groups are “small” > such that they can be enforced by the protocol. > > We have a lighting use case and desire for another use case. We need > more discussion around that. > Also from my discussions with my co -chair and AD, a discussion around > cipher suites should be considered, given TLS 1.3 has specified AEAD > cipher suites. > > Can you get behind this way forward for the next meeting? > > Thanks, > Dorothy > > > > > In light of the > On Oct 3, 2014, at 8:01 AM, Rene Struik > wrote: > >> Hi Dorothy: >> >> Apologies for responding late to this (I was away last week and only >> slowly catching up on email). >> >> I have gone through all the email regarding multicast security since >> Thu Sept 18, 2014, but saw lots of posturing, but not too much >> technical analysis of the problem space. >> >> Main questions: >> a) Is source authentication vs. group authentication technically >> feasible within typical use case constraints? What are these constraints? >> Note: it is hard to find the codification of these constraints. {In >> other groups, one often uses ballparks of human perception time >> latencies of 250ms.} >> b) Is source authentication vs. group authentication desirable? >> Note: it seems this is certainly so for control messaging and perhaps >> for others (I have only seen the light presence sensor and broadcast >> of "switch on" example by Sandeep Kumar >> (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), although >> Michael St. Johns gave a more futuristic "flock of drones" example >> (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). >> The effect of messaging includes a state change on the recipient. I >> would expect some analysis of what to do in case of diagnosis (e.g., >> to find source of problem in lighting system or, in the case of >> drones, to figure out why that $2m drone suddenly crashed...). >> c) Is source authentication expensive? >> Note: the usual "certificates are expensive" argument has been touted >> by Sandeep Kumar >> (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html). >> >> The discussion I have seen focuses on static groups and "light bulb >> scenarios". This makes me wonder about this from a system perspective. >> >> Further questions: >> d) What happens if group membership changes? >> Note: group membership changes should trigger a security event and an >> update of group keys (with some trade-off in granularity vs. security >> policy invariants). This was indirectly alluded to by Michael St. >> Johns >> (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html). >> e) How are group keys distributed in the first place? >> Note: there has not been too much discussion on the mailing list as >> to how one sets up a secure channel in the first place, esp. in >> heterogeneous settings (e.g., not just a single vendor solution -- >> Philips Lighting only, say). There are possibilities to implement >> homogeneous trust domain solutions, such as HIMMO, but these (a) >> still require a secure channel for distribution of key shares; (b) >> are not designed with heterogeneous trust domain (multi-vendor >> operations) in mind. >> >> I think it would behoove the group to have a clarify these questions, >> via a technical discussion, rather than political posturing. >> >> Some related discussion prior to the IETF-90 meeting in Toronto (the >> "Tyranny of the lightswitch" email series triggered by Michael St. >> Johns) seems to suggest that the answer to question #a above may very >> well be affirmative (message #322 is by STMicro): >> http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html >> http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html >> >> Most posturing seems to be motivated by a desire to use symmetric-key >> only constructs. This may be fine, but does not necessarily address >> system level questions and the question how one can build systems >> that draw from multiple vendors this way. >> >> Best regards, Rene >> >> -------- Forwarded Message -------- >> Subject: [Dtls-iot] DTLS multicast security >> Date: Thu, 18 Sep 2014 13:41:06 -0700 >> From: Dorothy Gellert >> To: dtls-iot@ietf.org >> >> >> >> Dear WG, >> >> Last week our AD and the WG chairs, myself and Zach, met to discuss the progress of the DTLS multicast security Work Item. >> it seems as though we have reach an impasse with regards to the issues raised on the mailing list with multicast security and DTLS. >> >> If this is the consensus of the WG we can progress the WG without this Work item and move forward with the other 2 work items, the dtls profile and practical issues around the DTLS handshake. >> >> I’d like to request feedback from the WG on this plan. >> >> Thanks, >> Dorothy >> >> >> >> >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >> >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080908050103010702010100 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Dorothy:

Most of the posturing seems to have been triggered not so much by technical arguments as to merits of source authentication vs. group authentication, but by some parties simply not wishing to risk having to implement public key functionality.

My email suggests that this posturing may be short-sighted and seemingly incompatible with the ultimate reason to even do standardization: facilitating deployments of systems with components from multiple vendors. In the end, one should be interested in having tools to build secure systems, not in Pyrrhus victories.

I know that some people opted for option "A" on the email list last week, but those preferences seemed to lack technical justification (anything else was just moved, again, to another group -- ACE?). As such, I find this approach a poor man's justification the IETF unworthy.

I think bringing technical merit discussion back on the table makes sense. We can roll up our sleeves and do some technical work or make this into a voting machinery (which I think IETF portends not to be). Even if one just wishes to stick with poor man's solutions, it would be good to finally get technical requirements on the table (e.g., re time latency, etc.), which has all been severely lacking so far.

Just ask yourself: why does it take 8 weeks of absolute silence since IETF-90 to suddenly get a flurry of posturing emails when multicast is mentioned by you in an email, with no technical arguments exchanged to justify option A? This may be a way to partition a problem, but has little to do with looking for a long-term viable technical mechanism for multicast.

BTW - here are my perspectives on the questions I posed:
a) Is source authentication vs. group authentication technically feasible within typical use case constraints? YES, feasible (without even the need to sign every message, so hybrid symmetric/public key approach possible). See also some emails of July 2014. What are these constraints? Let us stick with 250 ms time latency, failing further concise problem statements.
b) Is source authentication vs. group authentication desirable? Yes, for control messages. Just implement accross the board, to preclude feature creep of group authentication (which will happen - IETF cannot prevent people misusing constructs, so simply do not provide them).
c) Is source authentication expensive? No. See technical data points, Hannes Tschofenig's ARM speaker organized webcast, certs in consumer space virtually for free, etc.
d) What happens if group membership changes? Change of group membership requires a point to point secure channel update, thereby source authentication.
e) How are group keys distributed in the first place? Heterogeneous deployments, also in the lighting arena, require a heterogeneous lifecycle model, which is scalable with public-key technology. If one needs this anyway (why standardize otherwise, instead of having companies all do their own thing?), one could use the primitive also for source authentication in multi-cast setting.

Rene

On 10/3/2014 2:25 PM, Dorothy Gellert wrote:
Hi Rene,

Thanks for your comments.   When I read through your questions it seems what you referring to  in terms of system perspective is something along the lines of Best Practices section that
would address the questions you pose, such as diagnosis and group membership.   Key distribution was decided at the BoF to be out of band, but can be described in a Best Practices section or document. 

So far we have generated rough consensus around coap application based group use cases that require confidentiality only.   This is our problem statement we agreed we needed at the last IETF meeting. 
I also believe we have made the case that theses groups are “small” such that they can be enforced by the protocol.

We have a lighting use case and desire for another use case.  We need more discussion around that. 
Also from my discussions with my co -chair and AD, a discussion around cipher suites should be considered, given TLS 1.3  has specified AEAD cipher suites. 

Can you get behind this way forward for the next meeting?

Thanks,
Dorothy




In light of the 
On Oct 3, 2014, at 8:01 AM, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Dorothy:

Apologies for responding late to this (I was away last week and only slowly catching up on email).

I have gone through all the email regarding multicast security since Thu Sept 18, 2014, but saw lots of posturing, but not too much technical analysis of the problem space.

Main questions:
a) Is source authentication vs. group authentication technically feasible within typical use case constraints? What are these constraints?
Note: it is hard to find the codification of these constraints. {In other groups, one often uses ballparks of human perception time latencies of 250ms.}
b) Is source authentication vs. group authentication desirable?
Note: it seems this is certainly so for control messaging and perhaps for others (I have only seen the light presence sensor and broadcast of "switch on" example by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), although Michael St. Johns gave a more futuristic "flock of drones" example (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). The effect of messaging includes a state change on the recipient. I would expect some analysis of what to do in case of diagnosis (e.g., to find source of problem in lighting system or, in the case of drones, to figure out why that $2m drone suddenly crashed...).
c) Is source authentication expensive?
Note: the usual "certificates are expensive" argument has been touted by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html).

The discussion I have seen focuses on static groups and "light bulb scenarios". This makes me wonder about this from a system perspective.

Further questions:
d) What happens if group membership changes?
Note: group membership changes should trigger a security event and an update of group keys (with some trade-off in granularity vs. security policy invariants). This was indirectly alluded to by Michael St. Johns (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html).
e) How are group keys distributed in the first place?
Note: there has not been too much discussion on the mailing list as to how one sets up a secure channel in the first place, esp. in heterogeneous settings (e.g., not just a single vendor solution -- Philips Lighting only, say). There are possibilities to implement homogeneous trust domain solutions, such as HIMMO, but these (a) still require a secure channel for distribution of key shares; (b) are not designed with heterogeneous trust domain (multi-vendor operations) in mind.

I think it would behoove the group to have a clarify these questions, via a technical discussion, rather than political posturing.

Some related discussion prior to the IETF-90 meeting in Toronto (the "Tyranny of the lightswitch" email series triggered by Michael St. Johns) seems to suggest that the answer to question #a above may very well be affirmative (message #322 is by STMicro):
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html

Most posturing seems to be motivated by a desire to use symmetric-key only constructs. This may be fine, but does not necessarily address system level questions and the question how one can build systems that draw from multiple vendors this way.

Best regards, Rene

-------- Forwarded Message --------
Subject: [Dtls-iot] DTLS multicast security
Date: Thu, 18 Sep 2014 13:41:06 -0700
From: Dorothy Gellert <dorothy.gellert@gmail.com>
To: dtls-iot@ietf.org 


Dear WG,

Last week our AD and the WG chairs, myself and Zach, met to discuss the progress of the DTLS multicast security Work Item. 
it seems as though we have reach an impasse with regards to the issues raised on the mailing list with multicast security and DTLS.     

If this is the consensus of the WG  we can progress the WG without this Work item and move forward with the other 2 work items, the dtls profile and practical issues around the DTLS handshake.   

I’d like to request feedback from the WG on this plan.

Thanks, 
Dorothy 





_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot


_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------080908050103010702010100-- From nobody Fri Oct 3 12:01:05 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964B41A88C0 for ; Fri, 3 Oct 2014 12:01:01 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 H_xUeb_JQSn8 for ; Fri, 3 Oct 2014 12:01:00 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5021A888B for ; Fri, 3 Oct 2014 12:00:59 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id w8so1295603qac.9 for ; Fri, 03 Oct 2014 12:00:59 -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 :content-transfer-encoding; bh=bBQSzq5z7R2HvyixJT5A2tP5hUYlq+xNogz2UST69vg=; b=coaz83e0L/RduiCvkXgTN3ckTqeuXvB0MN1UQ1fVMuYBtXCORCXv9frz0YYt9jdkSp RNrrIeDHLdpTdJzp4lYTS4zEAUS20uNv+fLUhQlGJ0FdvKFQCkm/RkXN3bq+o7ik5QzS 6U5TttFMQivqDp3gm5hRabgVVHQitnx7H9VqKqc7elOv/KyVO6mXeqGCDsHuC8I2Qr8P dq9ZvuktAC5V4dgk/YWfOeGNiHLjgUaKF3MYr/Cr9VNlvoubpz7TOXjksx0+iXFiuQqr /niPzk7uCZLw+hBiBRb0w/l5W4s841F1KsKFiswDPsOHKRdO0p5P0aXZrvad/G5BTzFH xD3Q== X-Gm-Message-State: ALoCoQmbpsMNtO6cgCZQTQrxXKuucsENHpRVkJGDoXKqff/7es+gt757Smjc8JvQ27Cg7sdc5Lcd X-Received: by 10.140.90.42 with SMTP id w39mr8059625qgd.88.1412362858976; Fri, 03 Oct 2014 12:00:58 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:dd:bc45:b86d:ec25:aec3? ([2601:a:2a00:dd:bc45:b86d:ec25:aec3]) by mx.google.com with ESMTPSA id o7sm6416684qay.4.2014.10.03.12.00.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Oct 2014 12:00:58 -0700 (PDT) Message-ID: <542EF272.7060909@nthpermutation.com> Date: Fri, 03 Oct 2014 15:01:06 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <542EBA5D.5090105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/-vpBKjUZmWGO2K4eO6VHoVL4GgQ Subject: Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:01:01 -0000 On 10/3/2014 2:25 PM, Dorothy Gellert wrote: > So far we have generated rough consensus around coap application based > group use cases that require confidentiality only. That's not exactly correct. What I think we got was consensus that symmetric key multicast control wasn't going to fly and that symmetric key multicast confidentiality might be useful. However, at this point the only use case described in draft-keoh... - lighting - doesn't actually require confidentiality. So we're still a solution in search of a problem. Mike From nobody Fri Oct 3 12:29:34 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E8B1A1A79 for ; Fri, 3 Oct 2014 12:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 ka89FjjR1dIC for ; Fri, 3 Oct 2014 12:29:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB811A887F for ; Fri, 3 Oct 2014 12:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s93JTKOL026752; Fri, 3 Oct 2014 21:29:20 +0200 (CEST) Received: from [172.20.10.7] (ip-109-45-1-252.web.vodafone.de [109.45.1.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3253981; Fri, 3 Oct 2014 21:29:18 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <542EF272.7060909@nthpermutation.com> Date: Fri, 3 Oct 2014 21:29:15 +0200 X-Mao-Original-Outgoing-Id: 434057355.770591-846ec371de73a4720963757335245630 Content-Transfer-Encoding: quoted-printable Message-Id: <4D1BC205-3C21-47AF-A472-9F8ABF507B4F@tzi.org> References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <542EBA5D.5090105@gmail.com> <542EF272.7060909@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/OR8oEoVa-YRB3UpdnQE9aofREgk Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:29:25 -0000 On 03 Oct 2014, at 21:01, Michael StJohns = wrote: > What I think we got was consensus that symmetric key multicast control = wasn't going to fly and that symmetric key multicast confidentiality = might be useful. Control is not a security service. I don=92t think there is consensus that group authentication is not = useful. In any case, it is hard to do confidentiality without some form of = authentication. I live in a world where the loudly stated arguments about group = authentication being dangerous and asymmetric crypto being =93cheap" = just don=92t apply. Apparently, I have been unable to show some of you = this world. I just spent another two days in a workshop on systems and = products where this is so patently obvious that words escape me. So I = don=92t think we can have consensus between the IoT security view and = the loudly stated military/banking security view here. draft-mglt-dice-ipsec-for-application-payload-00 demonstrates that = existing IETF standards track protocols suffice to solve the problem at = hand, except maybe for a lack of optimization. So maybe this is where = those interested in solving this problem need to continue their work. Gr=FC=DFe, Carsten From nobody Fri Oct 3 12:40:26 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3001A1A6A for ; Fri, 3 Oct 2014 12:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, LOTS_OF_MONEY=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 tDoShJIk-YRQ for ; Fri, 3 Oct 2014 12:40:08 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A131A19EC for ; Fri, 3 Oct 2014 12:40:08 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id v63so1266463oia.13 for ; Fri, 03 Oct 2014 12:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VWgQATdh9f6ZOdKp3j/r07x85NZmbCMz6Fli8HJJASU=; b=de4+bd87q2LbEa17s019YadtlKqbLJLUmK7gf38JKnH1xI3wulXGrT5UjkJZtzU5Z1 8HlRFI5Mn2LaPvzl4k6wU5b+PXu0KNKINnoIX+Y3vpVvN7LehfDLOuytRQY0ppbS7wpV bNHKVFGBc6UoiQEVZrRA7pO8KHMjWPeMzP2XdhavSYMsscmpdYQNbGErWfTbepPd4Vg7 ex93EE6A2h/tQXVnTLq0JDHHB7RSBHeSKWPWmmJLWRmAnJVwwZqnK5eMHXPo4ov2nbIU yjm4ikrD+vKp4Pn4zn4y+AyIKd90itNW4Zo7TSSNHraGtNtvMS1yb7YjoVeUpEVZfcIz Mbpg== X-Received: by 10.182.126.233 with SMTP id nb9mr9618181obb.46.1412365207757; Fri, 03 Oct 2014 12:40:07 -0700 (PDT) Received: from [192.168.1.205] (c-50-174-103-180.hsd1.ca.comcast.net. [50.174.103.180]) by mx.google.com with ESMTPSA id y5sm4822253oet.15.2014.10.03.12.40.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 12:40:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5F02D782-2250-462D-A4DE-36BA8724748B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dorothy Gellert In-Reply-To: <542EF092.3060708@gmail.com> Date: Fri, 3 Oct 2014 12:39:56 -0700 Message-Id: <8D714138-2823-400D-9FB3-A7B062580895@gmail.com> References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <542EBA5D.5090105@gmail.com> <542EF092.3060708@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/z-6xjMyEEehqr2hzgk5AN5AAOs0 Cc: "Gellert, Dorothy" , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:40:13 -0000 --Apple-Mail=_5F02D782-2250-462D-A4DE-36BA8724748B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Rene- As a co-chair I brought up the multicast security work item in an = attempt find a way to move the item forward or to remove it. There was = support among the vocal members of the list to restrict the work item to = restrict to confidentiality only,=20 in light of the technical arguments made on the list. I don=92t want = to keep re-hashing old arguments especially if they don=92t promote a = way forward. You comments on system perspective are valid, and to propose a way = forward I suggested a best practices consideration, as multicast = security will be used with application protocols not specified by this = group (coap). I=92m glad to see you answer the questions you proposed=85. it seems you = have a solution in mind. I believe it would be helpful to put that = idea into a draft that the WG can evaluate it in entirety.=20 Thanks, Dorothy On Oct 3, 2014, at 11:53 AM, Rene Struik wrote: > Hi Dorothy: >=20 > Most of the posturing seems to have been triggered not so much by = technical arguments as to merits of source authentication vs. group = authentication, but by some parties simply not wishing to risk having to = implement public key functionality. >=20 > My email suggests that this posturing may be short-sighted and = seemingly incompatible with the ultimate reason to even do = standardization: facilitating deployments of systems with components = from multiple vendors. In the end, one should be interested in having = tools to build secure systems, not in Pyrrhus victories. >=20 > I know that some people opted for option "A" on the email list last = week, but those preferences seemed to lack technical justification = (anything else was just moved, again, to another group -- ACE?). As = such, I find this approach a poor man's justification the IETF unworthy. >=20 > I think bringing technical merit discussion back on the table makes = sense. We can roll up our sleeves and do some technical work or make = this into a voting machinery (which I think IETF portends not to be). = Even if one just wishes to stick with poor man's solutions, it would be = good to finally get technical requirements on the table (e.g., re time = latency, etc.), which has all been severely lacking so far.=20 >=20 > Just ask yourself: why does it take 8 weeks of absolute silence since = IETF-90 to suddenly get a flurry of posturing emails when multicast is = mentioned by you in an email, with no technical arguments exchanged to = justify option A? This may be a way to partition a problem, but has = little to do with looking for a long-term viable technical mechanism for = multicast.I men > BTW - here are my perspectives on the questions I posed: > a) Is source authentication vs. group authentication technically = feasible within typical use case constraints? YES, feasible (without = even the need to sign every message, so hybrid symmetric/public key = approach possible). See also some emails of July 2014. What are these = constraints? Let us stick with 250 ms time latency, failing further = concise problem statements. > b) Is source authentication vs. group authentication desirable? Yes, = for control messages. Just implement accross the board, to preclude = feature creep of group authentication (which will happen - IETF cannot = prevent people misusing constructs, so simply do not provide them). > c) Is source authentication expensive? No. See technical data points, = Hannes Tschofenig's ARM speaker organized webcast, certs in consumer = space virtually for free, etc. > d) What happens if group membership changes? Change of group = membership requires a point to point secure channel update, thereby = source authentication. > e) How are group keys distributed in the first place? Heterogeneous = deployments, also in the lighting arena, require a heterogeneous = lifecycle model, which is scalable with public-key technology. If one = needs this anyway (why standardize otherwise, instead of having = companies all do their own thing?), one could use the primitive also for = source authentication in multi-cast setting. >=20 > Rene >=20 > On 10/3/2014 2:25 PM, Dorothy Gellert wrote: >> Hi Rene, >>=20 >> Thanks for your comments. When I read through your questions it = seems what you referring to in terms of system perspective is something = along the lines of Best Practices section that >> would address the questions you pose, such as diagnosis and group = membership. Key distribution was decided at the BoF to be out of band, = but can be described in a Best Practices section or document.=20 >>=20 >> So far we have generated rough consensus around coap application = based group use cases that require confidentiality only. This is our = problem statement we agreed we needed at the last IETF meeting.=20 >> I also believe we have made the case that theses groups are =93small=94= such that they can be enforced by the protocol. >>=20 >> We have a lighting use case and desire for another use case. We need = more discussion around that.=20 >> Also from my discussions with my co -chair and AD, a discussion = around cipher suites should be considered, given TLS 1.3 has specified = AEAD cipher suites.=20 >>=20 >> Can you get behind this way forward for the next meeting? >>=20 >> Thanks, >> Dorothy >>=20 >>=20 >>=20 >>=20 >> In light of the=20 >> On Oct 3, 2014, at 8:01 AM, Rene Struik = wrote: >>=20 >>> Hi Dorothy: >>>=20 >>> Apologies for responding late to this (I was away last week and only = slowly catching up on email). >>>=20 >>> I have gone through all the email regarding multicast security since = Thu Sept 18, 2014, but saw lots of posturing, but not too much technical = analysis of the problem space. >>>=20 >>> Main questions: >>> a) Is source authentication vs. group authentication technically = feasible within typical use case constraints? What are these = constraints? >>> Note: it is hard to find the codification of these constraints. {In = other groups, one often uses ballparks of human perception time = latencies of 250ms.} >>> b) Is source authentication vs. group authentication desirable? >>> Note: it seems this is certainly so for control messaging and = perhaps for others (I have only seen the light presence sensor and = broadcast of "switch on" example by Sandeep Kumar = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), = although Michael St. Johns gave a more futuristic "flock of drones" = example = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). = The effect of messaging includes a state change on the recipient. I = would expect some analysis of what to do in case of diagnosis (e.g., to = find source of problem in lighting system or, in the case of drones, to = figure out why that $2m drone suddenly crashed...).=20 >>> c) Is source authentication expensive? >>> Note: the usual "certificates are expensive" argument has been = touted by Sandeep Kumar = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html). >>>=20 >>> The discussion I have seen focuses on static groups and "light bulb = scenarios". This makes me wonder about this from a system perspective. >>>=20 >>> Further questions: >>> d) What happens if group membership changes? >>> Note: group membership changes should trigger a security event and = an update of group keys (with some trade-off in granularity vs. security = policy invariants). This was indirectly alluded to by Michael St. Johns = (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html). >>> e) How are group keys distributed in the first place? >>> Note: there has not been too much discussion on the mailing list as = to how one sets up a secure channel in the first place, esp. in = heterogeneous settings (e.g., not just a single vendor solution -- = Philips Lighting only, say). There are possibilities to implement = homogeneous trust domain solutions, such as HIMMO, but these (a) still = require a secure channel for distribution of key shares; (b) are not = designed with heterogeneous trust domain (multi-vendor operations) in = mind. >>>=20 >>> I think it would behoove the group to have a clarify these = questions, via a technical discussion, rather than political posturing. >>>=20 >>> Some related discussion prior to the IETF-90 meeting in Toronto (the = "Tyranny of the lightswitch" email series triggered by Michael St. = Johns) seems to suggest that the answer to question #a above may very = well be affirmative (message #322 is by STMicro): >>> http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html >>> http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html >>>=20 >>> Most posturing seems to be motivated by a desire to use = symmetric-key only constructs. This may be fine, but does not = necessarily address system level questions and the question how one can = build systems that draw from multiple vendors this way. >>>=20 >>> Best regards, Rene >>>=20 >>> -------- Forwarded Message -------- >>> Subject: [Dtls-iot] DTLS multicast security >>> Date: Thu, 18 Sep 2014 13:41:06 -0700 >>> From: Dorothy Gellert >>> To: dtls-iot@ietf.org >>>=20 >>> Dear WG, >>>=20 >>> Last week our AD and the WG chairs, myself and Zach, met to discuss = the progress of the DTLS multicast security Work Item.=20 >>> it seems as though we have reach an impasse with regards to the = issues raised on the mailing list with multicast security and DTLS. =20= >>>=20 >>> If this is the consensus of the WG we can progress the WG without = this Work item and move forward with the other 2 work items, the dtls = profile and practical issues around the DTLS handshake. =20 >>>=20 >>> I=92d like to request feedback from the WG on this plan. >>>=20 >>> Thanks,=20 >>> Dorothy=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dtls-iot mailing list >>> dtls-iot@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtls-iot >>>=20 >>>=20 >>> _______________________________________________ >>> dtls-iot mailing list >>> dtls-iot@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtls-iot >>=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --Apple-Mail=_5F02D782-2250-462D-A4DE-36BA8724748B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Rene-

As a co-chair I brought up the multicast = security work item in an attempt find a way to move the item forward or = to remove it.   There was support among the vocal members of the = list to restrict the work item to restrict to confidentiality = only, 
in light of the technical arguments made on the = list.   I don=92t want to keep re-hashing old arguments especially = if they don=92t promote a way forward.

You = comments on system perspective are valid, and to propose a way forward I = suggested a best practices consideration, as multicast security will be = used with application protocols not specified by this group = (coap).

I=92m glad to see you answer the = questions you proposed=85. it seems you have a solution in mind.   = I believe it would be helpful to put that idea into a draft that the WG = can evaluate it in = entirety. 

Thanks,
Dorothy


On Oct 3, 2014, at 11:53 AM, = Rene Struik <rstruik.ext@gmail.com> = wrote:

=20 =20
Hi Dorothy:

Most of the posturing seems to have been triggered not so much by technical arguments as to merits of source authentication vs. group authentication, but by some parties simply not wishing to risk having to implement public key functionality.

My email suggests that this posturing may be short-sighted and seemingly incompatible with the ultimate reason to even do standardization: facilitating deployments of systems with components from multiple vendors. In the end, one should be interested in having tools to build secure systems, not in Pyrrhus victories.

I know that some people opted for option "A" on the email list last week, but those preferences seemed to lack technical justification (anything else was just moved, again, to another group -- ACE?). As such, I find this approach a poor man's justification the IETF unworthy.

I think bringing technical merit discussion back on the table makes sense. We can roll up our sleeves and do some technical work or make this into a voting machinery (which I think IETF portends not to be). Even if one just wishes to stick with poor man's solutions, it would be good to finally get technical requirements on the table (e.g., re time latency, etc.), which has all been severely lacking so far.

Just ask yourself: why does it take 8 weeks of absolute silence since IETF-90 to suddenly get a flurry of posturing emails when multicast is mentioned by you in an email, with no technical arguments exchanged to justify option A? This may be a way to partition a problem, but has little to do with looking for a long-term viable technical mechanism for multicast.I men
BTW - here are my perspectives on the questions I posed:
a) Is source authentication vs. group authentication technically feasible within typical use case constraints? YES, = feasible (without even the need to sign every message, so hybrid = symmetric/public key approach possible). See also some emails of July 2014. What are these constraints? Let us stick with 250 ms time latency, failing further concise problem statements.
b) Is source authentication vs. group authentication desirable? = Yes, for control messages. Just implement accross the board, to = preclude feature creep of group authentication (which will happen - IETF cannot prevent people misusing constructs, so simply do not provide them).
c) Is source authentication expensive? No. See technical data points, Hannes Tschofenig's ARM speaker organized webcast, certs in consumer space virtually for free, etc.
d) What happens if group membership changes? Change of group membership requires a point to point secure channel update, thereby source authentication.
e) How are group keys distributed in the first place? = Heterogeneous deployments, also in the lighting arena, require a heterogeneous lifecycle model, which is scalable with public-key technology. If one needs this anyway (why standardize otherwise, instead of having companies all do their own thing?), one could use the primitive also for source authentication in multi-cast = setting.

Rene

On 10/3/2014 2:25 PM, Dorothy Gellert wrote:
= Hi Rene,

Thanks for your comments.   When I read through your questions it seems what you referring to  in terms of = system perspective is something along the lines of Best Practices section that
would address the questions you pose, such as diagnosis and group membership.   Key distribution was decided at the BoF = to be out of band, but can be described in a Best Practices section or document. 

So far we have generated rough consensus around coap application based group use cases that require confidentiality only.   This is our problem statement we agreed we needed = at the last IETF meeting. 
I also believe we have made the case that theses groups are =93small=94 such that they can be enforced by the = protocol.

We have a lighting use case and desire for another use case.  We need more discussion around that. 
Also from my discussions with my co -chair and AD, a discussion around cipher suites should be considered, given TLS 1.3  has specified AEAD cipher suites. 

Can you get behind this way forward for the next = meeting?

Thanks,
Dorothy




In light of the 
On Oct 3, 2014, at 8:01 AM, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Dorothy:

Apologies for responding late to this (I was away last week and only slowly catching up on email).

I have gone through all the email regarding multicast security since Thu Sept 18, 2014, but saw lots of posturing, but not too much technical analysis of the problem space.

Main questions:
a) Is source authentication vs. group authentication technically feasible within typical use case constraints? What are these constraints?
Note: it is hard to find the codification of these constraints. {In other groups, one often uses ballparks of human perception time latencies of 250ms.}
b) Is source authentication vs. group authentication desirable?
Note: it seems this is certainly so for control messaging and perhaps for others (I have only seen the light presence sensor and broadcast of "switch on" example by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html= ), although Michael St. Johns gave a more futuristic "flock of drones" example (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html= )). The effect of messaging includes a state change on the recipient. I would expect some analysis of what to do in case of diagnosis (e.g., to find source of problem in lighting system or, in the case of drones, to figure out why that $2m drone suddenly crashed...).
c) Is source authentication expensive?
Note: the usual "certificates are expensive" argument has been touted by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html= ).

The discussion I have seen focuses on static groups and "light bulb scenarios". This makes me wonder about this from a system perspective.

Further questions:
d) What happens if group membership changes?
Note: group membership changes should trigger a security event and an update of group keys (with some trade-off in granularity vs. security policy invariants). This was indirectly alluded to by Michael St. Johns (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html= ).
e) How are group keys distributed in the first place?
Note: there has not been too much discussion on the mailing list as to how one sets up a secure channel in the first place, esp. in heterogeneous settings (e.g., not just a single vendor solution -- Philips Lighting only, say). There are possibilities to implement homogeneous trust domain solutions, such as HIMMO, but these (a) still require a secure channel for distribution of key shares; (b) are not designed with heterogeneous trust domain (multi-vendor operations) in mind.

I think it would behoove the group to have a clarify these questions, via a technical discussion, rather than political posturing.

Some related discussion prior to the IETF-90 meeting in Toronto (the "Tyranny of the lightswitch" email series triggered by Michael St. Johns) seems to suggest that the answer to question #a above may very well be affirmative (message #322 is by STMicro):
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html=
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html=

Most posturing seems to be motivated by a desire to use symmetric-key only constructs. This may be fine, but does not necessarily address system level questions and the question how one can build systems that draw from multiple vendors this way.

Best regards, Rene

-------- Forwarded Message --------
Subject: [Dtls-iot] DTLS multicast security
Date: Thu, 18 Sep 2014 13:41:06 -0700
From: Dorothy Gellert <dorothy.gellert@gmail.com>= ;
To: dtls-iot@ietf.org 


Dear WG,

Last week our AD and the WG chairs, myself and Zach, met to discuss the =
progress of the DTLS multicast security Work Item.=20
it seems as though we have reach an impasse with regards to the issues =
raised on the mailing list with multicast security and DTLS.    =20

If this is the consensus of the WG  we can progress the WG without this =
Work item and move forward with the other 2 work items, the dtls profile =
and practical issues around the DTLS handshake.  =20

I=92d like to request feedback from the WG on this plan.

Thanks,=20
Dorothy=20





_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/dtls-iot


_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dtls-iot



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

= --Apple-Mail=_5F02D782-2250-462D-A4DE-36BA8724748B-- From nobody Sat Oct 11 22:12:10 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076141A8876 for ; Sat, 11 Oct 2014 22:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 2Ir6Haw4-Xlc for ; Sat, 11 Oct 2014 22:12:01 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3901A1A8867 for ; Sat, 11 Oct 2014 22:12:00 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id x12so3314080qac.3 for ; Sat, 11 Oct 2014 22:12:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ZObbSk5jWsvVQ4Z6E+lsg5AQn4lT/2lnFcIUhQXfQTw=; b=Y6S5AwN0v4jenLzJBKn6ncnAq4XmGqtT/esifGLp8KpbNis+/rRssMiYtEZBEZf+Zd gocZPDvGKAcrL/Khu/qJ2/tM1LZTawUsPSTEsrVygJzj9vTLVR/9WfQFed3eiO97kcez XRlaglHYor5SVNO/bSgr9qFEGhrzu8EBXUirm8Xhm8ABTM3e9Ra0Hd5iSHHRzsDxy3lK aYQKhAJoQ0bY6DErZdNdCW4Sj3Agp506r/qfdYl9kJUBfrDgZkWchbh+b4/qbcOdy/R1 iqA71LvGyDppxEAj5Qq5Tk0s/wjebzvLx8aiGv9SHPtgDGPPUTQxjDnQhV6QVSBcF7yO 4Z2Q== X-Gm-Message-State: ALoCoQmATig02xIL3Ivjljs5eizPo5qBiV/Jtn+WwWvpvptbgO1WXeEttmvP1J0OZ7euODo12Dpi MIME-Version: 1.0 X-Received: by 10.224.156.68 with SMTP id v4mr27166789qaw.74.1413090720006; Sat, 11 Oct 2014 22:12:00 -0700 (PDT) Received: by 10.140.25.199 with HTTP; Sat, 11 Oct 2014 22:11:59 -0700 (PDT) X-Originating-IP: [69.255.115.150] Date: Sun, 12 Oct 2014 01:11:59 -0400 Message-ID: From: "StJohns, Michael" To: "dtls-iot@ietf.org" Content-Type: multipart/alternative; boundary=089e0158c75a66decb050532d2ab Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/yV7YORgitGMWi7_JuvHCBxdw9Gg Subject: [Dtls-iot] Interesting article on IOT security from real world liability perspective X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 05:12:04 -0000 --089e0158c75a66decb050532d2ab Content-Type: text/plain; charset=UTF-8 http://money.cnn.com/2014/10/08/technology/security/internet-of-things-security/index.html?iid=HP_LN&hpt=hp_bn5 Mike --089e0158c75a66decb050532d2ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable http://money.cnn.c= om/2014/10/08/technology/security/internet-of-things-security/index.html?ii= d=3DHP_LN&hpt=3Dhp_bn5

Mike --089e0158c75a66decb050532d2ab-- From nobody Sat Oct 11 23:53:31 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3557D1A88F2; Sat, 11 Oct 2014 23:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 CQJ-YRyTlz9j; Sat, 11 Oct 2014 23:53:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E011A1AFB; Sat, 11 Oct 2014 23:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9C6rMaY013548; Sun, 12 Oct 2014 08:53:22 +0200 (CEST) Received: from [192.168.217.145] (p54891112.dip0.t-ipconnect.de [84.137.17.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 03B8DA6D; Sun, 12 Oct 2014 08:53:21 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Sun, 12 Oct 2014 08:53:20 +0200 X-Mao-Original-Outgoing-Id: 434789600.561424-2f9352141ba1efcc42ed177ff36ff23b Content-Transfer-Encoding: quoted-printable Message-Id: <0B1527DE-D410-421C-9870-EFA120F1AEA0@tzi.org> References: To: "StJohns, Michael" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/hWXUbJQYBHnaj2tYom8bDtArJLY Cc: "dtls-iot@ietf.org" , ace@ietf.org Subject: Re: [Dtls-iot] Interesting article on IOT security from real world liability perspective X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 06:53:28 -0000 On 12 Oct 2014, at 07:11, StJohns, Michael = wrote: > = http://money.cnn.com/2014/10/08/technology/security/internet-of-things-sec= urity/index.html?iid=3DHP_LN&hpt=3Dhp_bn5 If you take the effort to look at the vulnerabilities reported, it is = interesting to see that they are all exploiting the lame security model = for today=92s home networks: A single shared-key WiFi password that = grants access to everything. The LiFX vulnerability was caused by the light bulbs needing to tell = each other that shared-key WiFi password over the (unsecured) 802.15.4 = network. (Well, it was dumb enough to communicate that key in an = unsecured fashion, but the damage that LiFX could cause was much worse = due to the sensitivity of the WiFi key.) The Belkin camera vulnerability was caused by handing out the permanent = keys for cloud access to the camera to anyone that had access to the = WiFi network, even temporarily. (That was probably considered OK = because the shared-key protected home network is =93secure=94, no?) Instead of having this simple-minded perimeter security, we need to move = to real, authenticated authorization. That=92s what ACE is about. Of course, as long as the IoT devices need the WiFi password to access = the network, and other devices in the home rely on lame WiFi perimeter = security, those other devices will remain vulnerable to any bugs in the = IoT devices. If you want to keep those lame other devices, the only = solution here is to firewall them off. (Using IPv6 for the IoT devices = helps quite a way here.) The next time you read one of those dime-a-dozen articles about =93IoT = security=94, read closer and find out they are really a lament about = today=92s lame home network security model. Gr=FC=DFe, Carsten From nobody Sun Oct 12 01:40:47 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E6F1A8956; Sun, 12 Oct 2014 01:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 mTBwLSVLyPRY; Sun, 12 Oct 2014 01:40:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D06D1A1B69; Sun, 12 Oct 2014 01:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9C8eXPj015897; Sun, 12 Oct 2014 10:40:33 +0200 (CEST) Received: from [192.168.217.106] (p54891112.dip0.t-ipconnect.de [84.137.17.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 66B0CABA; Sun, 12 Oct 2014 10:40:32 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> Date: Sun, 12 Oct 2014 10:40:30 +0200 X-Mao-Original-Outgoing-Id: 434796030.617112-58a1dc33bdaf36152d29474fb6880c05 Content-Transfer-Encoding: quoted-printable Message-Id: <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, lwip@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/7h9c8FIh7cbcsStu2jGsZS1Uof0 Subject: [Dtls-iot] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 08:40:41 -0000 A first draft version of the IETF91 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution, so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 I notice there is no ROLL meeting in the agenda. The Constrained Node/Network group meetings are nicely spread out over = Mon-Thu, with a peak on Wednesday. I hope the social is bad, because that is about the only time between = the two CoRE meetings... All times are HST (UTC-1000) (use = https://datatracker.ietf.org/meeting/agenda-utc and press the button to = get your local time in case you want to listen in from remote). Gr=FC=DFe, Carsten MONDAY, November 10, 2014 0900-1130 Morning Session I Coral 2 APP appsawg Applications Area Working Group WG - = Combined with APPAREA Coral 4 OPS v6ops IPv6 Operations WG 1300-1500 Afternoon Session I Coral 4 RTG bier Bit Indexed Explicit Replication BOF 1520-1720 Afternoon Session II Coral 1 INT detnet Deterministic Networking BOF Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 3 OPS v6ops IPv6 Operations WG 1730-1830 Afternoon Session III Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 1 SEC *** dice DTLS In Constrained Environments WG TUESDAY, November 11, 2014 0900-1130 Morning Session I Coral 2 APP uta Using TLS in Applications WG Kahili 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Coral 5 TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Coral 1 APP httpbis Hypertext Transfer Protocol WG Coral 4 RTG rtgarea Routing Area Open Meeting Coral 2 TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Coral 2 APP *** core Constrained RESTful Environments WG Coral 5 RAI webpush Web-Based Push Notifications WG WEDNESDAY, November 12, 2014 0900-1130 Morning Session I Kahili 1/2 APP *** core Constrained RESTful Environments WG Coral 3 INT homenet Home Networking WG Lehua Suite SEC oauth Web Authorization Protocol WG Coral 4 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1300-1500 Afternoon Session I Coral 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Coral 4 APP httpbis Hypertext Transfer Protocol WG Kahili 1/2 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG THURSDAY, November 13, 2014 0900-1130 Morning Session I Coral 5 SEC tls Transport Layer Security WG Coral 2 TSV taps Transport Services WG 1300-1500 Afternoon Session I Coral 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG Coral 3 SEC saag Security Area Open Meeting Coral 1 TSV tsvwg Transport Area Working Group WG 1520-1620 Afternoon Session II Coral 4 INT *** lwig Light-Weight Implementation Guidance WG FRIDAY, November 14, 2014 0900-1130 Morning Session I Coral 3 INT 6man IPv6 Maintenance WG Coral 1 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Coral 4 INT intarea Internet Area Working Group WG Coral 2 SEC httpauth Hypertext Transfer Protocol = Authentication WG From nobody Sun Oct 12 13:11:09 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFE41A90F6 for ; Sun, 12 Oct 2014 13:11:05 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 k8VvWiEFxjAs for ; Sun, 12 Oct 2014 13:11:04 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0D51A90F1 for ; Sun, 12 Oct 2014 13:11:03 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z107so6026968qgd.13 for ; Sun, 12 Oct 2014 13:11:03 -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=vW/qN15vVZ96V1Iv0qfGDeuhByWhazc7kz5NvBwsTIU=; b=dvs0EFMlMZJWFCXZD4+T2YczrMHrkS9XR6npamu4nHkGwLV6FTZtIsi3ZSouXGDxIB R0CT98W8DIK8FbNj2rgbtDV5xuURvfeiI7JyXJfkIPvg6OSdcB4xXq2+WUype6Cv0L1P Z/y/iCtiBwPvb+EcyFdlw/d2Z4stFK7Cri2TBo/3ca1Km/Ja+Cf72YGl0HELC/kMkuAk y4Ji0gAyn875zwKONdqtEzJH/1hZo7f6deNyQDU8/oOapXS3WzzB0fihn8Z2a3W3bxds uMY843Rdz2OhD8qQlOzgUcjB3Me7ifc12ib/XR2HuZomnvCP5F1RB5gR5vUkvIxkiHsf xwXA== X-Gm-Message-State: ALoCoQnw5IOzGjmGCvgkAAqzP6kEKQ4piaV2WBN2PTwF3dGiv+XEp1jLCtvj+GKKxK/ZfAIv6aFr X-Received: by 10.229.29.3 with SMTP id o3mr33226892qcc.10.1413144663074; Sun, 12 Oct 2014 13:11:03 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:e7:a9a3:fe68:413b:c049? ([2601:a:2a00:e7:a9a3:fe68:413b:c049]) by mx.google.com with ESMTPSA id 17sm10789086qgj.32.2014.10.12.13.11.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Oct 2014 13:11:02 -0700 (PDT) Message-ID: <543AE069.7040407@nthpermutation.com> Date: Sun, 12 Oct 2014 16:11:21 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Carsten Bormann References: <0B1527DE-D410-421C-9870-EFA120F1AEA0@tzi.org> In-Reply-To: <0B1527DE-D410-421C-9870-EFA120F1AEA0@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/dTySdqiYcbR61Bw5dvJO80zvHtc Cc: "dtls-iot@ietf.org" , ace@ietf.org Subject: Re: [Dtls-iot] Interesting article on IOT security from real world liability perspective X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 20:11:06 -0000 On 10/12/2014 2:53 AM, Carsten Bormann wrote: > On 12 Oct 2014, at 07:11, StJohns, Michael wrote: > >> http://money.cnn.com/2014/10/08/technology/security/internet-of-things-security/index.html?iid=HP_LN&hpt=hp_bn5 > If you take the effort to look at the vulnerabilities reported, it is interesting to see that they are all exploiting the lame security model for today’s home networks: A single shared-key WiFi password that grants access to everything. > > The LiFX vulnerability was caused by the light bulbs needing to tell each other that shared-key WiFi password over the (unsecured) 802.15.4 network. (Well, it was dumb enough to communicate that key in an unsecured fashion, but the damage that LiFX could cause was much worse due to the sensitivity of the WiFi key.) > > The Belkin camera vulnerability was caused by handing out the permanent keys for cloud access to the camera to anyone that had access to the WiFi network, even temporarily. (That was probably considered OK because the shared-key protected home network is “secure”, no?) > > Instead of having this simple-minded perimeter security, we need to move to real, authenticated authorization. That’s what ACE is about. > > Of course, as long as the IoT devices need the WiFi password to access the network, and other devices in the home rely on lame WiFi perimeter security, those other devices will remain vulnerable to any bugs in the IoT devices. If you want to keep those lame other devices, the only solution here is to firewall them off. (Using IPv6 for the IoT devices helps quite a way here.) > > The next time you read one of those dime-a-dozen articles about “IoT security”, read closer and find out they are really a lament about today’s lame home network security model. > > Grüße, Carsten > It's kind of interesting how different my take away was from yours. (And, yes, I did read the article and read it closely so please give me the benefit of the doubt that I knew what I was doing when I offered the article instead of suggesting I didn't understand what I was reading). I didn't/don't really care that a vulnerability was related to X or Y, but that the vendor knew that its scheme was weak and provided the product anyway. The article wasn't about IOT security technology and I didn't present it as that (note the words "real world liability perspective" in the subject), but was an interesting look into the "ship or die" mentalities in a lot of product companies as it affects provision of good security technology in consumer products. All of the products were/are considered "IOT" or IOT precursors. All of them were provided with about the cheapest security possible, at least partly because that security was in wide deployment. There's no evidence that the product companies actually looked at the threat models for the environment that their products were going to be in. That's a continuing problem for companies, and sometimes a problem for the IETF and its working groups. Later, Mike From nobody Mon Oct 13 02:14:37 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE43F1A6F33; Mon, 13 Oct 2014 02:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 ok3mm8d6JsiA; Mon, 13 Oct 2014 02:14:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4111A6F2B; Mon, 13 Oct 2014 02:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9D9ESsf009085; Mon, 13 Oct 2014 11:14:28 +0200 (CEST) Received: from [134.102.218.214] (dynamic-218-o.informatik.uni-bremen.de [134.102.218.214]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 655EAF6; Mon, 13 Oct 2014 11:14:28 +0200 (CEST) Message-ID: <543B97F1.9010207@tzi.de> Date: Mon, 13 Oct 2014 11:14:25 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Michael StJohns , Carsten Bormann References: <0B1527DE-D410-421C-9870-EFA120F1AEA0@tzi.org> <543AE069.7040407@nthpermutation.com> In-Reply-To: <543AE069.7040407@nthpermutation.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/x3WijsXP55Y3jQmmI9gV9fHRrKI Cc: "dtls-iot@ietf.org" , ace@ietf.org Subject: Re: [Dtls-iot] Interesting article on IOT security from real world liability perspective X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 09:14:36 -0000 Hi Mike, On 10/12/2014 10:11 PM, Michael StJohns wrote: > On 10/12/2014 2:53 AM, Carsten Bormann wrote: >> On 12 Oct 2014, at 07:11, StJohns, Michael >> wrote: >> >>> http://money.cnn.com/2014/10/08/technology/security/internet-of-things-security/index.html?iid=HP_LN&hpt=hp_bn5 The article seems a bit sensation-seeking to me.. what exactly was your point in posting it? If your intent is to point out that we need security even for the smallest devices, I completely agree with you. If you want to point out that it is easy to do security wrong, I also agree with you. I think one big problem in current developments in this area is that there are no standardized security solutions for devices with strong limitations in terms of processing power, storage space etc. Vendors will come up with their own solutions which likely will have a lot of security problems. We could decide to refuse to develop protocols for this type of devices and let those people go on with their own solution (I don't really expect them to stop using those devices). Or we can design protocols that are able to cope with the limitations of the devices and provide the best possible security. Best regards, Steffi From nobody Mon Oct 13 03:22:09 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFE01A8969; Mon, 13 Oct 2014 03:22:04 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 xQvSdrxkqs68; Mon, 13 Oct 2014 03:21:58 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan3.extendcp.co.uk [79.170.43.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684BC1A6F93; Mon, 13 Oct 2014 03:21:58 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XdclI-0008RC-EE; Mon, 13 Oct 2014 11:21:56 +0100 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XdclG-0000vq-3s; Mon, 13 Oct 2014 11:21:56 +0100 Received: from host81-132-242-250.range81-132.btcentralplus.com ([81.132.242.250] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XdclD-0004Xk-8U; Mon, 13 Oct 2014 11:21:51 +0100 Message-ID: <543BA7BC.7040900@gridmerge.com> Date: Mon, 13 Oct 2014 11:21:48 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stefanie Gerdes , Michael StJohns , Carsten Bormann References: <0B1527DE-D410-421C-9870-EFA120F1AEA0@tzi.org> <543AE069.7040407@nthpermutation.com> <543B97F1.9010207@tzi.de> In-Reply-To: <543B97F1.9010207@tzi.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070609050506080503040105" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/OUV57mfwPSBcfwtYq5do9YwffnU Cc: "dtls-iot@ietf.org" , ace@ietf.org Subject: Re: [Dtls-iot] [Ace] Interesting article on IOT security from real world liability perspective X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 10:22:04 -0000 This is a cryptographically signed message in MIME format. --------------ms070609050506080503040105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable I think Mike's "ship or die" comment is very relevant. The problem with=20 security is that it is not necessary to have it to function. A door=20 without a lock is still a door. Therefore, the easiest corner to cut for = a product is security as it is still possible to show products working=20 without security in place. From that point of view, it is inevitable=20 that early releases of products will have vulnerabilities, some of them=20 significant. This will lead to sensationalist articles such as this,=20 promoting the services of "security experts" who often have some snake=20 oil solution which will cure everything. However, I agree that the presence of standards and and subsequent=20 multi-vendor support building it in to platforms, especially constrained = platforms, will make it easier to produce products with "invisible=20 security", i.e. baked in and virtually transparent to the actual=20 function of the product. There is some way to go before we get there but = that should be the goal and hopefully the ACE WG will help to achieve=20 that goal. Robert On 13/10/2014 10:14 AM, Stefanie Gerdes wrote: > Hi Mike, > > > On 10/12/2014 10:11 PM, Michael StJohns wrote: >> On 10/12/2014 2:53 AM, Carsten Bormann wrote: >>> On 12 Oct 2014, at 07:11, StJohns, Michael >>> wrote: >>> >>>> http://money.cnn.com/2014/10/08/technology/security/internet-of-thin= gs-security/index.html?iid=3DHP_LN&hpt=3Dhp_bn5 > The article seems a bit sensation-seeking to me.. what exactly was your= > point in posting it? If your intent is to point out that we need > security even for the smallest devices, I completely agree with you. If= > you want to point out that it is easy to do security wrong, I also agre= e > with you. > > I think one big problem in current developments in this area is that > there are no standardized security solutions for devices with strong > limitations in terms of processing power, storage space etc. Vendors > will come up with their own solutions which likely will have a lot of > security problems. > > We could decide to refuse to develop protocols for this type of devices= > and let those people go on with their own solution (I don't really > expect them to stop using those devices). Or we can design protocols > that are able to cope with the limitations of the devices and provide > the best possible security. > > Best regards, > Steffi > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --------------ms070609050506080503040105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDEwMTMxMDIxNDhaMCMGCSqGSIb3DQEJBDEWBBRVLUVwKJfKBiNnYsVJ+51d0CyN0TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQCcA+285cJX1aHHZudtMAULmWBqCAggwxV3 mWsNuSn5/f1xXZv8+ESy/Ivnz5beK2A2wcPRJdHs8SwxQ8u0SN+YCU3gqOenu9GSOnNaIPbI S4hpH5HiVks2iGfy9irtPVqb2WTzr4qKJcM4v9NW0NQalilWv8iTbIJ4pF1WW0HtEyTnDLXz ItKCVuRkd41EgZfqhQinPlr5VkqrGnfQN+LPm0J3HJHOCYAH7R1/XsXzHpCV+piqax/lKllh nm56SvQgO3B0FAdTQlz2jPR57Gvy09NSKtk2RLotZbZcc2HWtpIkNZ5cNF5NSSMAlw2t2gGo AtpNEbDP7x9MGN6vAuG1AAAAAAAA --------------ms070609050506080503040105-- From nobody Mon Oct 13 03:54:18 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9841F1A8989; Mon, 13 Oct 2014 03:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, SPF_HELO_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 rlsOkmydwDrr; Mon, 13 Oct 2014 03:54:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F135F1A0183; Mon, 13 Oct 2014 03:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9DArmXR024342; Mon, 13 Oct 2014 12:53:48 +0200 (CEST) Received: from [192.168.217.145] (p54893EA6.dip0.t-ipconnect.de [84.137.62.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 59E281E9; Mon, 13 Oct 2014 12:53:47 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <543BA7BC.7040900@gridmerge.com> Date: Mon, 13 Oct 2014 12:53:45 +0200 X-Mao-Original-Outgoing-Id: 434890425.566031-5a950fba5bf3bf7119412e36e4e7bec2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B1527DE-D410-421C-9870-EFA120F1AEA0@tzi.org> <543AE069.7040407@nthpermutation.com> <543B97F1.9010207@tzi.de> <543BA7BC.7040900@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/sWbcGrsBx9_mkFmZ9YkmYAdJr1A Cc: Stefanie Gerdes , ace@ietf.org, "dtls-iot@ietf.org" , Michael StJohns Subject: Re: [Dtls-iot] [Ace] Interesting article on IOT security from real world liability perspective X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 10:54:07 -0000 On 13 Oct 2014, at 12:21, Robert Cragie = wrote: > I think Mike's "ship or die" comment is very relevant.=20 I completely agree. Unfortunately, there is very little that we can do about this in the = IETF. I believe it is worth analyzing the unsavory situation we are in, to = some greater detail. =97 even if the companies wanted, they don=92t have (and cannot afford) = the engineering in house that could be tasked to create a secure product = (there is one exception in the consumer electronics space, and their = track record still isn=92t exactly stellar) =97 there is little economic incentive to be secure (no teeth in the = product liability) =97 sales and thus economic success is dominated by =93ease of use=94 =97 and this is amplified by the need to minimize costly customer care = contacts =97 ease of use is dominated by =97 expectations of users (plug and play etc.) =97 you can=92t actually be more secure in a way that causes hassle = that users don=92t expect =97 interoperability with what=92s already there =97 which includes deployed systems with abysmal security =97 that might damage the security of the IoT gear if it relies on = that =97 or bugs/unforeseen interactions of the IoT gear might damage = the =93security=94 of deployed systems It is very hard to secure home IoT if that needs to plug into and = interact with other networked home gear in its current insecure state. = My only hope is that if IoT gear can be made to lead in usable security, = that might shift expectations. It seems we=92ll have to do some of the = engineering here that the gear makers can=92t. We also need to spend more time pointing out that, if it isn=92t usably = secure, it=92s *not* IoT. Gr=FC=DFe, Carsten From nobody Mon Oct 13 07:08:31 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8220E1A8AEA; Mon, 13 Oct 2014 07:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 47SbQ3mzzTzz; Mon, 13 Oct 2014 07:08:02 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF15E1A1AB5; Mon, 13 Oct 2014 07:08:01 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id uq10so10533246igb.13 for ; Mon, 13 Oct 2014 07:08:01 -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:date:message-id:subject :from:to:cc:content-type; bh=jfihb82DIIkdckPyB32OtbTYa9yeSny+IPB5ndh0Eso=; b=EKB0sf/S8RQbXDSEd8U/BtqU94EFs4mE2vDI8SpzJfDBCwVrXQHUkP+lyEHhk6OxWh Q8zV6c0xtplrRp9t0eMwFLnfkRqxoAjQgNvwjjF1C0+aQMKvZILva/4lDvfb4tQj2JYw hyspeVBu01WwhyWPKqFvHpShQwgf+zZonSqKQq/+dkWH2/+SoSoq8B6pushVtSHdNO8b vGDfbuPxq0eJbmFt9CiCt1qjTl0HWQ0LGSoACfK/v5eM3G8m6hy/aT1rljVJQAGYQhe0 x5U/ZsBb7vsiu/0uq+bFeTzv9m2OjAWeOqeRGMh8PRt5BI8qCDzVuvaZzuxQI5WSNvcx 1fbg== MIME-Version: 1.0 X-Received: by 10.42.236.142 with SMTP id kk14mr37427059icb.9.1413209281164; Mon, 13 Oct 2014 07:08:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.163.3 with HTTP; Mon, 13 Oct 2014 07:08:01 -0700 (PDT) In-Reply-To: <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> Date: Mon, 13 Oct 2014 10:08:01 -0400 X-Google-Sender-Auth: M0_EFXlEBh63nqszumW0mnOngpc Message-ID: From: Barry Leiba To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Rnzy3r1_-b_8aoXsv7MXWcj2V3U Cc: lwip@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, dtls-iot@ietf.org, core , ace@ietf.org Subject: Re: [Dtls-iot] Constrained Node/Network Cluster @ IETF91, early draft version X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:08:04 -0000 Do you think the conflict between CORE and WEBPUSH is an issue that we should try to resolve? Barry From nobody Mon Oct 13 18:20:16 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6851A1A73; Mon, 13 Oct 2014 18:20:13 -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 6s8pKrs1Iccx; Mon, 13 Oct 2014 18:20:11 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22811A1A72; Mon, 13 Oct 2014 18:20:10 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id y10so6501684pdj.37 for ; Mon, 13 Oct 2014 18:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OfOnOjiUb+NSBd+BGgHlSGmhe7gKMq+nwUd9z4AIk0A=; b=ZM2oEXtL9T4rEjlVdfkFcplvJ/L1j0tDHMxFozn1jpZOYOweLTD9GXB0Q5PISL9rOP KntLpPjK4A5AlXh/sHGA1C6jZZDMaeHkr6KaG8NRg9vD7WMtaiEogFEjcnMQOISJtW13 Mb6wE0bZAFnTL3qV3/DT+fyWf5qwjm823tU7cernwT30EuKHuP6DME/Gg6vkOpSXFgl+ AV+Bc8s2SRRSKMpn5nf5QpbwKUQI4paBLRHeYMppSPYg7oV1t4pMkvXM08Ienxqtd7n+ FLUAV4t7xvygpo6ZyvkCMk+3E6jY5GA7cQKIzDKtBTePljINTzG8siS4b7JRM2JOzjOe uoaA== X-Received: by 10.66.124.136 with SMTP id mi8mr1458724pab.105.1413249610560; Mon, 13 Oct 2014 18:20:10 -0700 (PDT) Received: from [192.168.0.100] ([203.230.193.47]) by mx.google.com with ESMTPSA id fn2sm12338978pdb.75.2014.10.13.18.20.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 18:20:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_402E8211-9928-42CF-81AE-13DB60ABBC57" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jong-Hyouk Lee In-Reply-To: Date: Tue, 14 Oct 2014 10:18:52 +0900 Message-Id: <6010AC77-D2E4-413B-B94F-DC3EF0933EC0@gmail.com> References: <0B1527DE-D410-421C-9870-EFA120F1AEA0@tzi.org> <543AE069.7040407@nthpermutation.com> <543B97F1.9010207@tzi.de> <543BA7BC.7040900@gridmerge.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/HLnApaGMG4UhmqWe_03A9BLO6NM Cc: robert.cragie@gridmerge.com, Michael StJohns , ace@ietf.org, "dtls-iot@ietf.org" , Stefanie Gerdes Subject: Re: [Dtls-iot] [Ace] Interesting article on IOT security from real world liability perspective X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 01:20:13 -0000 --Apple-Mail=_402E8211-9928-42CF-81AE-13DB60ABBC57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that the article is one of dime-a-dozen articles while such = security vulnerabilities were happened due to the =E2=80=9Cship or = die=E2=80=9D mentalities, which are needed these days especially to = startups. I bet that such security vulnerabilities will be continuously = reported and the IETF cannot help much for solving those things happen. = The IETF is just one of standardization development organizations. J. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon On 2014. 10. 13., at =EC=98=A4=ED=9B=84 7:53, Carsten Bormann = wrote: > On 13 Oct 2014, at 12:21, Robert Cragie = wrote: >=20 >> I think Mike's "ship or die" comment is very relevant.=20 >=20 > I completely agree. >=20 > Unfortunately, there is very little that we can do about this in the = IETF. >=20 > I believe it is worth analyzing the unsavory situation we are in, to = some greater detail. >=20 > =E2=80=94 even if the companies wanted, they don=E2=80=99t have (and = cannot afford) the engineering in house that could be tasked to create a = secure product (there is one exception in the consumer electronics = space, and their track record still isn=E2=80=99t exactly stellar) > =E2=80=94 there is little economic incentive to be secure (no teeth in = the product liability) > =E2=80=94 sales and thus economic success is dominated by =E2=80=9Cease = of use=E2=80=9D > =E2=80=94 and this is amplified by the need to minimize costly = customer care contacts > =E2=80=94 ease of use is dominated by > =E2=80=94 expectations of users (plug and play etc.) > =E2=80=94 you can=E2=80=99t actually be more secure in a way that = causes hassle that users don=E2=80=99t expect > =E2=80=94 interoperability with what=E2=80=99s already there > =E2=80=94 which includes deployed systems with abysmal security > =E2=80=94 that might damage the security of the IoT gear if it = relies on that > =E2=80=94 or bugs/unforeseen interactions of the IoT gear might = damage the =E2=80=9Csecurity=E2=80=9D of deployed systems >=20 > It is very hard to secure home IoT if that needs to plug into and = interact with other networked home gear in its current insecure state. = My only hope is that if IoT gear can be made to lead in usable security, = that might shift expectations. It seems we=E2=80=99ll have to do some = of the engineering here that the gear makers can=E2=80=99t. >=20 > We also need to spend more time pointing out that, if it isn=E2=80=99t = usably secure, it=E2=80=99s *not* IoT. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_402E8211-9928-42CF-81AE-13DB60ABBC57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree that the article is one of dime-a-dozen articles while such = security vulnerabilities were happened due to the =E2=80=9Cship or = die=E2=80=9D mentalities, which are needed these days especially to = startups. I bet that such security vulnerabilities will be continuously = reported and the IETF cannot help much for solving those things happen. = The IETF is just one of standardization development = organizations.

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., Sangmyung = University


On 2014. 10. 13., at =EC=98=A4=ED=9B=84 7:53, Carsten = Bormann <cabo@tzi.org> = wrote:

On 13 Oct 2014, at 12:21, Robert Cragie <robert.cragie@gridmerge.com> wrote:

I think Mike's "ship or = die" comment is very relevant.

I completely = agree.

Unfortunately, there is very little that we can do about = this in the IETF.

I believe it is worth analyzing the unsavory = situation we are in, to some greater detail.

=E2=80=94 even if = the companies wanted, they don=E2=80=99t have (and cannot afford) the = engineering in house that could be tasked to create a secure product = (there is one exception in the consumer electronics space, and their = track record still isn=E2=80=99t exactly stellar)
=E2=80=94 there is = little economic incentive to be secure (no teeth in the product = liability)
=E2=80=94 sales and thus economic success is dominated by = =E2=80=9Cease of use=E2=80=9D
 =E2=80=94 and this is amplified = by the need to minimize costly customer care contacts
=E2=80=94 ease = of use is dominated by
 =E2=80=94 expectations of users (plug = and play etc.)
   =E2=80=94 you can=E2=80=99t = actually be more secure in a way that causes hassle that users don=E2=80=99= t expect
 =E2=80=94 interoperability with what=E2=80=99s = already there
   =E2=80=94 which includes deployed = systems with abysmal security
     =E2=80=94 = that might damage the security of the IoT gear if it relies on that
=      =E2=80=94 or bugs/unforeseen interactions = of the IoT gear might damage the =E2=80=9Csecurity=E2=80=9D of deployed = systems

It is very hard to secure home IoT if that needs to plug = into and interact with other networked home gear in its current insecure = state.  My only hope is that if IoT gear can be made to lead in = usable security, that might shift expectations.  It seems we=E2=80=99= ll have to do some of the engineering here that the gear makers = can=E2=80=99t.

We also need to spend more time pointing out that, = if it isn=E2=80=99t usably secure, it=E2=80=99s *not* = IoT.

Gr=C3=BC=C3=9Fe, = Carsten

_______________________________________________
Ace = mailing list
Ace@ietf.org
https://www.ietf.org/mail= man/listinfo/ace

= --Apple-Mail=_402E8211-9928-42CF-81AE-13DB60ABBC57-- From nobody Tue Oct 14 09:12:44 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A151A89FC for ; Tue, 14 Oct 2014 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=unavailable 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 KGCBeTudIm6E for ; Tue, 14 Oct 2014 09:12:39 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09881A89B4 for ; Tue, 14 Oct 2014 09:12:38 -0700 (PDT) X-ASG-Debug-ID: 1413303157-06daaa3ff5218f30001-roOjxa Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id SQdUw1RRQ3pf6Gu3; Tue, 14 Oct 2014 12:12:37 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Oct 2014 12:12:37 -0400 Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Oct 2014 12:12:36 -0400 Received: from KAINITE.InterDigital.com (10.1.64.252) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Oct 2014 12:12:36 -0400 Received: from NALENITE.InterDigital.com (10.2.64.253) by KAINITE.InterDigital.com (10.1.64.252) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Oct 2014 12:12:36 -0400 Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 12:12:35 -0400 From: "Rahman, Akbar" To: Carsten Bormann , "StJohns, Michael" Thread-Topic: "Apple Stores Will Sell a Smart Lock for Your Front Door" X-ASG-Orig-Subj: "Apple Stores Will Sell a Smart Lock for Your Front Door" Thread-Index: Ac/nyVL5OonVDSArTYKvZlrzlFq6dw== Date: Tue, 14 Oct 2014 16:12:34 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F01F404@NABESITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.1.133] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2014 16:12:36.0670 (UTC) FILETIME=[AB606DE0:01CFE7C9] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1413303157 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.10560 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/pmx4BKneGIshPFuTdRZGu1NbhZc Cc: "dtls-iot@ietf.org" , "ace@ietf.org" Subject: [Dtls-iot] "Apple Stores Will Sell a Smart Lock for Your Front Door" X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:12:41 -0000 Hi Carsten/Michael, (And changing the Email subject) I found this article also very interesting (and it contained some relevant = references to the smart lights and electronic keys use cases that had been = previously discussed on these lists). http://www.businessweek.com/articles/2014-10-14/apple-stores-will-sell-yves= -behars-smart-lock-for-homekit#r=3Dread =20 Best Regards, Akbar -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Sunday, October 12, 2014 2:53 AM To: StJohns, Michael Cc: dtls-iot@ietf.org; ace@ietf.org Subject: Re: [Ace] [Dtls-iot] Interesting article on IOT security from real= world liability perspective On 12 Oct 2014, at 07:11, StJohns, Michael wrote: > http://money.cnn.com/2014/10/08/technology/security/internet-of-things-se= curity/index.html?iid=3DHP_LN&hpt=3Dhp_bn5 If you take the effort to look at the vulnerabilities reported, it is inter= esting to see that they are all exploiting the lame security model for toda= y's home networks: A single shared-key WiFi password that grants access to = everything. The LiFX vulnerability was caused by the light bulbs needing to tell each o= ther that shared-key WiFi password over the (unsecured) 802.15.4 network. = (Well, it was dumb enough to communicate that key in an unsecured fashion, = but the damage that LiFX could cause was much worse due to the sensitivity = of the WiFi key.) The Belkin camera vulnerability was caused by handing out the permanent key= s for cloud access to the camera to anyone that had access to the WiFi netw= ork, even temporarily. (That was probably considered OK because the shared= -key protected home network is "secure", no?) Instead of having this simple-minded perimeter security, we need to move to= real, authenticated authorization. That's what ACE is about. Of course, as long as the IoT devices need the WiFi password to access the = network, and other devices in the home rely on lame WiFi perimeter security= , those other devices will remain vulnerable to any bugs in the IoT devices= . If you want to keep those lame other devices, the only solution here is = to firewall them off. (Using IPv6 for the IoT devices helps quite a way he= re.) The next time you read one of those dime-a-dozen articles about "IoT securi= ty", read closer and find out they are really a lament about today's lame h= ome network security model. Gr=FC=DFe, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Sat Oct 18 04:35:48 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17CE1A6FB9; Sat, 18 Oct 2014 04:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 stMgleWfmA9Y; Sat, 18 Oct 2014 04:35:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B671A6F9A; Sat, 18 Oct 2014 04:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9IBZWHE000960; Sat, 18 Oct 2014 13:35:33 +0200 (CEST) Received: from [192.168.217.113] (p54892213.dip0.t-ipconnect.de [84.137.34.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7A253E12; Sat, 18 Oct 2014 13:35:32 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> Date: Sat, 18 Oct 2014 13:35:31 +0200 X-Mao-Original-Outgoing-Id: 435324931.27575-9f5700bb96d21423e37a9b0134ec2caf Content-Transfer-Encoding: quoted-printable Message-Id: References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> <300A8653-4B32-40AB-8DB3-EE8EA3F1C2C7@tzi.org> To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, lwip@ietf.org X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/o_GvbSVjs7ZrBgwrlDOQeyLBAXQ Subject: Re: [Dtls-iot] Constrained Node/Network Cluster @ IETF91, "final" version X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 11:35:41 -0000 On 12 Oct 2014, at 10:40, Carsten Bormann wrote: > A first draft version of the IETF91 agenda is out. > ** THIS IS GOING TO CHANGE ** for conflict resolution, > so please don't make travel arrangements based on it. >=20 > Here is my usual eclectic condensed agenda built from that. =20 > All times are HST (UTC-1000) (use = https://datatracker.ietf.org/meeting/agenda-utc and press the button to = get your local time in case you want to listen in from remote). Here is an update with the =93final=94 agenda (caveat viator). Note the 6TiSCH move, and the newly scheduled JOSE meeting (across DICE, = ouch). Gr=FC=DFe, Carsten MONDAY, November 10, 2014 0900-1130 Morning Session I Coral 2 APP appsawg Applications Area Working Group WG - = Combined with APPAREA Coral 4 OPS v6ops IPv6 Operations WG 1300-1500 Afternoon Session I Coral 4 RTG bier Bit Indexed Explicit Replication BOF 1520-1720 Afternoon Session II Coral 1 INT detnet Deterministic Networking BOF Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 3 OPS v6ops IPv6 Operations WG 1730-1830 Afternoon Session III Coral 5 OPS anima Autonomic Networking Integrated Model = and Approach BOF Coral 1 SEC *** dice DTLS In Constrained Environments WG Rainbow Ste 1/2 SEC jose Javascript Object Signing and Encryption = WG TUESDAY, November 11, 2014 0900-1130 Morning Session I Coral 2 APP uta Using TLS in Applications WG Kahili 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Coral 5 TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Coral 1 APP httpbis Hypertext Transfer Protocol WG Coral 4 RTG rtgarea Routing Area Open Meeting Coral 2 TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Coral 2 APP *** core Constrained RESTful Environments WG Coral 5 RAI webpush Web-Based Push Notifications WG WEDNESDAY, November 12, 2014 0900-1130 Morning Session I Kahili 1/2 APP *** core Constrained RESTful Environments WG Coral 3 INT homenet Home Networking WG Lehua Suite SEC oauth Web Authorization Protocol WG Coral 4 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1300-1500 Afternoon Session I Coral 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Coral 4 APP httpbis Hypertext Transfer Protocol WG THURSDAY, November 13, 2014 0900-1130 Morning Session I Hibiscus 1/2 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Coral 5 SEC tls Transport Layer Security WG Coral 2 TSV taps Transport Services WG 1300-1500 Afternoon Session I Coral 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG Coral 3 SEC saag Security Area Open Meeting Coral 1 TSV tsvwg Transport Area Working Group WG 1520-1620 Afternoon Session II Coral 4 INT *** lwig Light-Weight Implementation Guidance WG FRIDAY, November 14, 2014 0900-1130 Morning Session I Coral 3 INT 6man IPv6 Maintenance WG Coral 1 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Coral 4 INT intarea Internet Area Working Group WG Coral 2 SEC httpauth Hypertext Transfer Protocol = Authentication WG From nobody Sun Oct 26 12:23:05 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41811A03A5; Sun, 26 Oct 2014 12:23:02 -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] 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 PFl2lDGKdMpH; Sun, 26 Oct 2014 12:23:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 753191A0382; Sun, 26 Oct 2014 12:23:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026192301.17648.31672.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 12:23:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/2BbfHEt7iSEdCop_qJ9ALfmjXsg Cc: dtls-iot@ietf.org Subject: [Dtls-iot] I-D Action: draft-ietf-dice-profile-05.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 19:23:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DTLS In Constrained Environments Working Group of the IETF. Title : A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet of Things Author : Hannes Tschofenig Filename : draft-ietf-dice-profile-05.txt Pages : 25 Date : 2014-10-26 Abstract: This document defines a DTLS 1.2 profile that is suitable for Internet of Things applications and is reasonably implementable on many constrained devices. A common design pattern in IoT deployments is the use of a constrained device (typically providing sensor data) that interacts with the web infrastructure. This document focuses on this particular pattern. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dice-profile-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dice-profile-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/