From nobody Wed Aug 5 07:54:57 2015 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 CE8A81B2E7D for ; Wed, 5 Aug 2015 07:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4Yb5XkDwIPu for ; Wed, 5 Aug 2015 07:54:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABAD1B2E7A for ; Wed, 5 Aug 2015 07:54:54 -0700 (PDT) Received: from [217.140.96.140] by 3capp-gmx-bs46.server.lan (via HTTP); Wed, 5 Aug 2015 16:54:44 +0200 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "FOSSATI, Thomas (Thomas)" Content-Type: text/html; charset=UTF-8 Date: Wed, 5 Aug 2015 16:54:44 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie>, X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:IRIbh7ZeAk4O0CCZgji0SCSF/6aoPqGgnKjOjadBjRA Qr8cd8cRlJp3G+hT3DQWL8pGGyFR8lqF3JSiwoqQYJ2CA9PcEy vZd7qdrtssr+Af0qLADRr11jRsuf58MzcwyAGzk4EJMMQMYwZD eh38pCDSJUfVWymXwoFMa3qgL8oD6pH2M9hca8O5pTsEpEY8jn 0DhudZhKpYxDWyHCM72aSrGOQI7sTmmBb7LdqnqOt6UDN26gYU 1QLsH/MWtx6jzYsxZDz5czvxqSuV9j2392xUP7Sh1ZnOONwU0h lvrhSQ= X-UI-Out-Filterresults: notjunk:1;V01:K0:2EIT7dWgrQo=:tApAuW59RbaAhzWh52ARei md+fv2TGQSewI++x88N9T4yWeKM+19+UULGVR/hpVW1Oml4Lcu6W1CoT9PYGrGiCPmS22sCSV DazoqtnGzg2Ztt01Ef5K67BLLi2OpD/R56jT6/V4p0RrUYr7xrP86Z1oqIjV62qtBI0SNqoPg uBLXCtIZBM12uVDrreE4cCMq2+kyt4ctAD4nWtdEBsOsofmj9nrPycKRNplVBhw4CUpEze4w6 Fm7WVxPG2Zv9jD62iXh3sLqWma3nQp1f+cmBloyWdRh0SHFH1ycRsDCe2cobIsPPul0wwmZnd zQ8VON/DE0K5pE2W4SJZUnjJCWOEClbelRRfXk48RaxxlfagoIclp/I1nz6IF4ai45Wt1Paov c83Qz8FRIPtGU9JRpsj2l+qWeoz5o+mgmfTFNXtMYbfB6OYqaAtBYWYHFixlbbnacVF/pa0+u lh5Por/LLg== Archived-At: Cc: "dtls-iot@ietf.org" , Stephen Farrell Subject: Re: [Dtls-iot] IP Addresses in Certificates 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: Wed, 05 Aug 2015 14:54:56 -0000
Hi Stephen, 
 
reading through this issue again I believe you could help us further explain what we could recommend in the document. 
 
Currently, we are saying that folks shouldn't use IP addresses in certificates and in the email below Thomas mentioned one reason for doing so. I also pointed to a separate draft we have been working on to explore the topic further (see <draft-fossati-core-certmode-rd-names-01>). 
 
Ciao
Hannes
Gesendet: Dienstag, 21. Juli 2015 um 14:16 Uhr
Von: "FOSSATI, Thomas (Thomas)" <thomas.fossati@alcatel-lucent.com>
An: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "Hannes Tschofenig" <hannes.tschofenig@gmx.net>, "dtls-iot@ietf.org" <dtls-iot@ietf.org>
Betreff: Re: [Dtls-iot] IP Addresses in Certificates
Hi Stephen,

On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell"
<dtls-iot-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:
>Hiya,
>
>On 15/07/15 12:07, Hannes Tschofenig wrote:
>> Stephen wrote:
>>
>> (5) 6.3: Forgetting CoAP for the moment, surely this profile will be
>> used with devices that only have (possibly bogon) IP addresses and that
>> want to have those in certs. I do get that how to handle that well is
>> not very clear, esp. for certs for e.g. 192.168.0.1, but shouldn't it
>> really be covered by this profile?
>
>I should also have mentioned link-local addresses too I guess.

v6 link-local make sense as stable identifiers, but they'd be equivalent
to EUI-64 (which is what 6.3.2 requires for the use case where all the
secure communication happens on the same subnet), only a few bytes larger
than their EUI counterpart.

Other kinds of IP addresses aren't long-term/stable enough to be put in a
certificate -- which is in line with the recommendation we give in CoAP
[https://tools.ietf.org/html/rfc7252#section-9.1.3.3].

Cheers, t

_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot
From nobody Wed Aug 5 09:47:29 2015 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 5FA3C1B3136 for ; Wed, 5 Aug 2015 09:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5Cm2BLPtVvh for ; Wed, 5 Aug 2015 09:47:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAD41B30E8 for ; Wed, 5 Aug 2015 09:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C055ABE88; Wed, 5 Aug 2015 17:47:23 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCMxfkVra60d; Wed, 5 Aug 2015 17:47:23 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E5BABE7C; Wed, 5 Aug 2015 17:47:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438793243; bh=hd1uLsm5leM3SeRXrWUDyNSaA/Ei1cLQV4jUAWHll20=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=bgyxL5dSQWjHHQ5Wu81EI6fEiBPnl+Y44p0t0gNafDdPShp32+T+DX18VHPxuEulR R1CJ2PQGYSMck52q2H0NgH8sQjgEwrCOINBdj35XpMmzXtwnOLTFI1owtCFMOs5ftA 9C/ZVNDEDWu2VC9YuzggROcfMmfa2zVimIWMUlSU= Message-ID: <55C23E1B.5050300@cs.tcd.ie> Date: Wed, 05 Aug 2015 17:47:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Hannes Tschofenig , "FOSSATI, Thomas (Thomas)" References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie>, In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] IP Addresses in Certificates 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: Wed, 05 Aug 2015 16:47:27 -0000 Hiya, On 05/08/15 15:54, Hannes Tschofenig wrote: > Hi Stephen, > reading through this issue again I believe you could help us further explain > what we could recommend in the document. Assuming that it'd be a bunch of work to recommend how to best handle certificates for devices that will only ever have a bogon IP address, I guess the best for now is to just say that that work is not (yet) done and hence this document makes no recommendation. Seem ok? (And yes it could be that the current text on that is just fine, I didn't go look back right now) S. > Currently, we are saying that folks shouldn't use IP addresses in certificates > and in the email below Thomas mentioned one reason for doing so. I also pointed > to a separate draft we have been working on to explore the topic further (see > ). > Ciao > Hannes > *Gesendet:* Dienstag, 21. Juli 2015 um 14:16 Uhr > *Von:* "FOSSATI, Thomas (Thomas)" > *An:* "Stephen Farrell" , "Hannes Tschofenig" > , "dtls-iot@ietf.org" > *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates > Hi Stephen, > > On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell" > wrote: > >Hiya, > > > >On 15/07/15 12:07, Hannes Tschofenig wrote: > >> Stephen wrote: > >> > >> (5) 6.3: Forgetting CoAP for the moment, surely this profile will be > >> used with devices that only have (possibly bogon) IP addresses and that > >> want to have those in certs. I do get that how to handle that well is > >> not very clear, esp. for certs for e.g. 192.168.0.1, but shouldn't it > >> really be covered by this profile? > > > >I should also have mentioned link-local addresses too I guess. > > v6 link-local make sense as stable identifiers, but they'd be equivalent > to EUI-64 (which is what 6.3.2 requires for the use case where all the > secure communication happens on the same subnet), only a few bytes larger > than their EUI counterpart. > > Other kinds of IP addresses aren't long-term/stable enough to be put in a > certificate -- which is in line with the recommendation we give in CoAP > [https://tools.ietf.org/html/rfc7252#section-9.1.3.3]. > > Cheers, t > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot > From nobody Wed Aug 5 12:48:24 2015 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 BBD7E1A8764 for ; Wed, 5 Aug 2015 12:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUPlKzrPpkqH for ; Wed, 5 Aug 2015 12:48:15 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7671A1B4C for ; Wed, 5 Aug 2015 12:48:15 -0700 (PDT) Received: by qgeh16 with SMTP id h16so37963459qge.3 for ; Wed, 05 Aug 2015 12:48:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=fGhjPWj036opov815HyjnmDf8VfOY4ZrXz4M4K6Xy9k=; b=EWfYP43hsVZOVyAjFC9TuTVAM9HgckhD/OAfY4CWX2gHv4ptT1mX3r1uCDQU8wyPjK XnK/nzak0CifvTOFLYHs6TUPueN0BaNUxCqBs907TGlCiWYzMMV7jdvgGElQIKrGjDoE o9tj/nqyABoqUABkaIcDJ4vN4Bl2Bhdk5H4M1NQHs21c6vQd0Xp2Wor5rKBe5TjEAXdk DjwNLb50fu5tYzoVIf/XMgazKGGXf4r1RsU4YoEWK6IP+cMdG9nK6A2EkfxnfZvrjo/l xIAwbHk1sxg/im5EuH1UmfiCYlWXC32p+rk5op/LVndHFQDuvZLEVSct/W6/YG7dKwLK piEQ== X-Gm-Message-State: ALoCoQlJD+iaS01pyVxcGBd4b4dycwp3pdviIMWcKewEPNkkPLK897jhGLwB/kogutNLmyHXS6PI X-Received: by 10.140.30.166 with SMTP id d35mr19518043qgd.85.1438804094272; Wed, 05 Aug 2015 12:48:14 -0700 (PDT) Received: from ?IPv6:2601:148:c000:1bb4:9858:21af:6dd7:5528? ([2601:148:c000:1bb4:9858:21af:6dd7:5528]) by smtp.gmail.com with ESMTPSA id 20sm1920380qkp.39.2015.08.05.12.48.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 12:48:13 -0700 (PDT) To: dtls-iot@ietf.org References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> <55C23E1B.5050300@cs.tcd.ie> From: Michael StJohns Message-ID: <55C2687F.8050004@nthpermutation.com> Date: Wed, 5 Aug 2015 15:48:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55C23E1B.5050300@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dtls-iot] IP Addresses in Certificates 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: Wed, 05 Aug 2015 19:48:22 -0000 Hi Stephen et al. I'm coming in on this fairly late (2 weeks) so let me try and muddy the waters: IEEE 802.1AR is a good source for ideas of how to deal with certificates and small devices. In the case of Zigbee Smart Energy 2.0 for example, we use their concepts of LDevID (Locally significant) and IDevID (Initial) device identifiers. The latter is what gets built into the device and SEP2.0 uses the SubjectAltName hardwareModuleName in RFC4108 as the manufactured in name for the device. The attachment of a certificate to MAC address or even IP address by the manufacturer has a number of issues that are painful to address and that don't usually add to the security of the system. (e.g. the handle of the name mostly isn't important to the underlying protocols in IOT and the relationship between an entity and its IP or MAC generally isn't a necessary consideration for trust between entities given certificates - same reason that client certificates for TLS rarely have IP addresses in them, but do have human personal names or email addresses). Ideally you want a mapping between what's on the certificate inside the device and what's on the label outside - so that humans can basically type things in (or barcode them or....) during installation. I might expect a local trust center to issue an LDevID based on the (manual?) acceptance of IDevID, and the LDevID *could* contain an IP address as a SubjectAltName, but I don't think we've gone that deep and most folk balk at running a Mini-CA in their home. So I think your recommendation of "future work needed" is probably more correct than "IP certificates needed". Later, Mike On 8/5/2015 12:47 PM, Stephen Farrell wrote: > Hiya, > > On 05/08/15 15:54, Hannes Tschofenig wrote: >> Hi Stephen, >> reading through this issue again I believe you could help us further explain >> what we could recommend in the document. > Assuming that it'd be a bunch of work to recommend how to best > handle certificates for devices that will only ever have a bogon > IP address, I guess the best for now is to just say that that work > is not (yet) done and hence this document makes no recommendation. > > Seem ok? (And yes it could be that the current text on that > is just fine, I didn't go look back right now) > > S. > >> Currently, we are saying that folks shouldn't use IP addresses in certificates >> and in the email below Thomas mentioned one reason for doing so. I also pointed >> to a separate draft we have been working on to explore the topic further (see >> ). >> Ciao >> Hannes >> *Gesendet:* Dienstag, 21. Juli 2015 um 14:16 Uhr >> *Von:* "FOSSATI, Thomas (Thomas)" >> *An:* "Stephen Farrell" , "Hannes Tschofenig" >> , "dtls-iot@ietf.org" >> *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates >> Hi Stephen, >> >> On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell" >> wrote: >> >Hiya, >> > >> >On 15/07/15 12:07, Hannes Tschofenig wrote: >> >> Stephen wrote: >> >> >> >> (5) 6.3: Forgetting CoAP for the moment, surely this profile will be >> >> used with devices that only have (possibly bogon) IP addresses and that >> >> want to have those in certs. I do get that how to handle that well is >> >> not very clear, esp. for certs for e.g. 192.168.0.1, but shouldn't it >> >> really be covered by this profile? >> > >> >I should also have mentioned link-local addresses too I guess. >> >> v6 link-local make sense as stable identifiers, but they'd be equivalent >> to EUI-64 (which is what 6.3.2 requires for the use case where all the >> secure communication happens on the same subnet), only a few bytes larger >> than their EUI counterpart. >> >> Other kinds of IP addresses aren't long-term/stable enough to be put in a >> certificate -- which is in line with the recommendation we give in CoAP >> [https://tools.ietf.org/html/rfc7252#section-9.1.3.3]. >> >> Cheers, t >> >> _______________________________________________ >> 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 > From nobody Thu Aug 6 03:00:36 2015 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 E23FA1B2BDB for ; Thu, 6 Aug 2015 03:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGOH9JjTPv03 for ; Thu, 6 Aug 2015 03:00:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABC21B2BD3 for ; Thu, 6 Aug 2015 03:00:33 -0700 (PDT) Received: from [217.140.96.140] by 3capp-gmx-bs27.server.lan (via HTTP); Thu, 6 Aug 2015 12:00:26 +0200 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "Hannes Tschofenig" Content-Type: text/html; charset=UTF-8 Date: Thu, 6 Aug 2015 12:00:26 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <55A6456E.4020806@gmx.net> References: <55A6456E.4020806@gmx.net> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:egQYfRtVKMoWY0JIVRdYSdX+CBCtACzvQIUj+yHiPxP xBp+SzWJUL9imhdx1dGQ3od/M4V396jHgvmNFszVcufuCJh53T lbmgLl8GNs9OCW8b1XUSqQKa8GJGy5VQn5rLKSXqHz/n5AWRyi kYcdYiiDm+AQ/21Su7Ad1Fn4XpUhTByMci2m8dnaDnZh/TcB7d COk8vGXtV/IZ6JQNSKSqzPbKJZ4QUzrkW2z7LalPjXWyKqUohK omBGyr/77vPNRpzWt6FnjYPcYW0RDSD05cg1T5nZT6rDUJKJwi O68dU8= X-UI-Out-Filterresults: notjunk:1;V01:K0:IDXSUYklZhw=:1qRE6Zw7rCSa+EY+GlaXva qkfgAFCSn2Qsdr8PMx9hPzlFzxlfE0tbh2GC0bKajFOVAicXuTh6La17F2bZCK3UK41/S81Bl hdjaYUS5l8x9lPh7nz2P+d4Kal7ozWx9451f36GtQS3qdGPhrcy3+/DUXjjmvAUOMsvUD9/lG /OTbMWM0WY8pXd2r2/LsHho8XIK1hpsb9zcxFj8CUpCEM6/ktaXOAYzZR6xd5RjFPSM7UVx4M 9O95BuqowgZb02A1gVjfm0u+cwN7m7rmzQCZV86RGaCfevhhcsdsBc5O0EiSTvWN0JtSIxvVJ M6AaE4/kzH26DMfodCa7vKEYoSqcyRoxR0BA27VYPNpgE23sLkjeH03HGUDK+Dm1vK/dMEZX8 pKKB94Vr2v0hPLxh28UP3p3Zgtf5sG0ur0sPyfnciPy+4yBc7epIDEd2JYwhyLIu4T6x0A9fp RrzSIlSVMQ== Archived-At: Cc: "dtls-iot@ietf.org" , Stephen Farrell Subject: Re: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement? 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: Thu, 06 Aug 2015 10:00:35 -0000
Hi all, Hi Stephen, 
 
I have sent the mail below to this mailing list in an attempt to solicit feedback from the DICE group after creating an issue in the issue tracker at http://trac.tools.ietf.org/wg/dice/trac/ticket/34
 
I have also posted a message to the CFRG list, see 
 
While I got a little bit of feedback on the CFRG list I am still unsure about how to proceed on this topic. 
 
There does not seem to be strong interest in using ChaCha20 and Poly1305. 
Currently, AES is in used in hardware of many embedded/IoT systems. It is also mandated in various standards, including radio technologies.
To my knowledge there is no hardware support for ChaCha20 and Poly1305 in chips today. 
 
Requiring ChaCha20 and Poly1305 in addition to AES would be possible on paper but will lead to additional flash space.
 
What should we do? 
 
Ciao
Hannes 
Gesendet: Mittwoch, 15. Juli 2015 um 13:35 Uhr
Von: "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
An: "dtls-iot@ietf.org" <dtls-iot@ietf.org>, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Betreff: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement?
Stephen wrote:

(11) 21: Why not make RFC7539 a SHOULD or MUST right now? Doesn't it
seem like doing so now in a profile would be the right kind of timing?
And that might be our best bet for healing the CCM/GCM rift so I'd like
to check if the WG agree with that idea or not before we go to IETF LC.
(That might justify a separate thread.)

This is really a question for the group to think about. Any comments?

_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot
From nobody Thu Aug 6 03:09:59 2015 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 1A79C1B2BCF for ; Thu, 6 Aug 2015 03:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL3uEl1rvZAz for ; Thu, 6 Aug 2015 03:09:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E2B1B2B3B for ; Thu, 6 Aug 2015 03:09:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EE42E377; Wed, 5 Aug 2015 15:58:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1D9F463B10; Wed, 5 Aug 2015 15:41:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0295D63AD9; Wed, 5 Aug 2015 15:41:06 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <55C23E1B.5050300@cs.tcd.ie> References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie>, <55C23E1B.5050300@cs.tcd.ie> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: Hannes Tschofenig , "FOSSATI, Thomas \(Thomas\)" , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] IP Addresses in Certificates 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: Thu, 06 Aug 2015 10:09:57 -0000 --=-=-= Content-Type: text/plain Stephen Farrell wrote: > On 05/08/15 15:54, Hannes Tschofenig wrote: >> Hi Stephen, reading through this issue again I believe you could help >> us further explain what we could recommend in the document. > Assuming that it'd be a bunch of work to recommend how to best handle > certificates for devices that will only ever have a bogon IP address, I > guess the best for now is to just say that that work is not (yet) done > and hence this document makes no recommendation. > Seem ok? (And yes it could be that the current text on that is just > fine, I didn't go look back right now) okay, but we need to do this work for ANIMA, and other places. I wrote: http://datatracker.ietf.org/doc/draft-richardson-6tisch-idevid-cert/ But elsewhere in this thread I mentioned a current killer-app need for this is with service processors (ILOM/iDRAC/...) which seldom have anything other than a rfc1918 dhcp address, and really, the browser location bar should show the end user the vendor and mac address of the unit, not the IP address. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVcJm0YCLcPvd0N1lAQKVhAf/VC3N25LQBzICSKpzop/LsYOMiPIY8cKH uK5cJRBgRVvVfTBjHfiCs/KzuprsAPssT89dOVfoPrPu5/wXIz2/yE/6H6LJEdOI 1NMZCNiymYz19d0nReuhGApwpMik7/MBil5LI4GS/AqK1IfLLaMJBx+6c8tZcM4O KZ3Jjp5VQ+oHSA01YGdjyDcwt+EgfDirxbvtfjsUdQNy0HHof2gdq8OZBlBgPt/n VErVCuZX1Lu9Lk0MYzog6KgWieN50ZR2mthoP4KbUanS0yAmgPUa5z66OMGhZJMk RNk0L9u3oxsjRtmn+SzS9gwwIybvPvKhlw3S0jLDyRwJPwJ+ZA3BmQ== =ep8i -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 6 06:27:38 2015 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 8C8971B2F54 for ; Thu, 6 Aug 2015 06:27:37 -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 k_0CDow04rih for ; Thu, 6 Aug 2015 06:27:35 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC08F1ACE02 for ; Thu, 6 Aug 2015 06:27:34 -0700 (PDT) Received: by ioeg141 with SMTP id g141so80715008ioe.3 for ; Thu, 06 Aug 2015 06:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=ehXWMdwJto9kmJuL8vkpsjN/d4zIhgjatiCAoWDpQxQ=; b=dLCg7c3eiaNzpve36lgLjKSQAPRq1S5ESRdDFYjhhbt4CicpddcW1Ge7jfCmSsCOJF zAlQL3TyOx0YktIZmbqMy+nkyqdvf1w5yG8poPvpIr5XlyZYQ4WkysZbHpOJCzXNwP22 7TrNmzH294jTmy/FIAJbyNjpX3y+NOUf11LOo8s+hJfJhwH8RQkdDtNTuHgINRSzjl9q b/j8J3xPR8AU9pb67OPa8ljpbYJpaOWwd7MTl7gaJLW7HVitAO5eOhuyncDOHWMfvj28 TJExMKhKVNoYkAuYFsn+bJPq7v5crq0i/RG/LhH/e3iLvKaWdeK0t6Wj1H6THvqby3Ma 34sQ== X-Received: by 10.107.28.67 with SMTP id c64mr1906176ioc.90.1438867654278; Thu, 06 Aug 2015 06:27:34 -0700 (PDT) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by smtp.gmail.com with ESMTPSA id q10sm1340820ige.16.2015.08.06.06.27.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 06:27:33 -0700 (PDT) To: Hannes Tschofenig References: <55A6456E.4020806@gmx.net> From: Rene Struik Message-ID: <55C360B0.8070307@gmail.com> Date: Thu, 6 Aug 2015 09:27:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000905000808060901090908" Archived-At: Cc: "dtls-iot@ietf.org" , Stephen Farrell Subject: Re: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement? 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: Thu, 06 Aug 2015 13:27:37 -0000 This is a multi-part message in MIME format. --------------000905000808060901090908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes: I do not think there is any technical or practical reason to add support for ChaCha or Poly1305. For very constrained devices, the required state is quite large, per-message key initialization cost is relatively high for short message, allowing starting processing of incoming packets after computation of those per-message keys only, and ChaCha20 keys are 256-bits. Most underlying transceivers already have AES on board, in hardware, and operate using 128-bit keys. Adding another mode does seem to impose cost, with unclear technical benefit, both on security and performance and implementation cost front. On a side note: the security of Salsa20/20 has been quite well analyzed (see, e.g., [1]), but - to my knowledge - this has not been extended to ChaCha. Best regards, Rene [1] Ciphers - Salsa20 Secure Against Differential Cryptanalysis (Nicky Mouha, Bart Preneel, IACR ePrint 2013-328) On 8/6/2015 6:00 AM, Hannes Tschofenig wrote: > Hi all, Hi Stephen, > I have sent the mail below to this mailing list in an attempt to > solicit feedback from the DICE group after creating an issue in the > issue tracker at http://trac.tools.ietf.org/wg/dice/trac/ticket/34 > I have also posted a message to the CFRG list, see > http://www.ietf.org/mail-archive/web/cfrg/current/msg07082.html > While I got a little bit of feedback on the CFRG list I am still > unsure about how to proceed on this topic. > There does not seem to be strong interest in using ChaCha20 and Poly1305. > Currently, AES is in used in hardware of many embedded/IoT systems. It > is also mandated in various standards, including radio technologies. > To my knowledge there is no hardware support for ChaCha20 and Poly1305 > in chips today. > Requiring ChaCha20 and Poly1305 in addition to AES would be possible > on paper but will lead to additional flash space. > What should we do? > Ciao > Hannes > *Gesendet:* Mittwoch, 15. Juli 2015 um 13:35 Uhr > *Von:* "Hannes Tschofenig" > *An:* "dtls-iot@ietf.org" , "Stephen Farrell" > > *Betreff:* [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST > implement? > Stephen wrote: > > (11) 21: Why not make RFC7539 a SHOULD or MUST right now? Doesn't it > seem like doing so now in a profile would be the right kind of timing? > And that might be our best bet for healing the CCM/GCM rift so I'd like > to check if the WG agree with that idea or not before we go to IETF LC. > (That might justify a separate thread.) > > This is really a question for the group to think about. Any comments? > > _______________________________________________ > 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 --------------000905000808060901090908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Hannes:

I do not think there is any technical or practical reason to add support for ChaCha or Poly1305.

For very constrained devices, the required state is quite large, per-message key initialization cost is relatively high for short message, allowing starting processing of incoming packets  
after computation of those per-message keys only, and ChaCha20 keys are 256-bits. Most underlying transceivers already have AES on board, in hardware, and operate using 128-bit keys. Adding another mode does seem to impose cost, with unclear technical benefit, both on security and performance and implementation cost front.

On a side note: the security of Salsa20/20 has been quite well analyzed (see, e.g., [1]), but - to my knowledge - this has not been extended to ChaCha.

Best regards, Rene

[1] Ciphers - Salsa20 Secure Against Differential Cryptanalysis (Nicky Mouha, Bart Preneel, IACR ePrint 2013-328)

On 8/6/2015 6:00 AM, Hannes Tschofenig wrote:
Hi all, Hi Stephen, 
 
I have sent the mail below to this mailing list in an attempt to solicit feedback from the DICE group after creating an issue in the issue tracker at http://trac.tools.ietf.org/wg/dice/trac/ticket/34
 
I have also posted a message to the CFRG list, see 
 
While I got a little bit of feedback on the CFRG list I am still unsure about how to proceed on this topic. 
 
There does not seem to be strong interest in using ChaCha20 and Poly1305. 
Currently, AES is in used in hardware of many embedded/IoT systems. It is also mandated in various standards, including radio technologies.
To my knowledge there is no hardware support for ChaCha20 and Poly1305 in chips today. 
 
Requiring ChaCha20 and Poly1305 in addition to AES would be possible on paper but will lead to additional flash space.
 
What should we do? 
 
Ciao
Hannes 
Gesendet: Mittwoch, 15. Juli 2015 um 13:35 Uhr
Von: "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
An: "dtls-iot@ietf.org" <dtls-iot@ietf.org>, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Betreff: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement?
Stephen wrote:

(11) 21: Why not make RFC7539 a SHOULD or MUST right now? Doesn't it
seem like doing so now in a profile would be the right kind of timing?
And that might be our best bet for healing the CCM/GCM rift so I'd like
to check if the WG agree with that idea or not before we go to IETF LC.
(That might justify a separate thread.)

This is really a question for the group to think about. Any comments?

_______________________________________________
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
--------------000905000808060901090908-- From nobody Thu Aug 6 06:40:27 2015 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 2D6A11B2FA1 for ; Thu, 6 Aug 2015 06:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clziFxB-qaOR for ; Thu, 6 Aug 2015 06:40:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026E21B2FBF for ; Thu, 6 Aug 2015 06:40:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD1C2BE4C; Thu, 6 Aug 2015 14:40:21 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MnUgH_rKYuJ; Thu, 6 Aug 2015 14:40:21 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C014BDCA; Thu, 6 Aug 2015 14:40:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438868421; bh=G8YyiP4VdugOkqxJM0NTvyAuBMSipdEiN4S9FiRrVS4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=NsXXnAa4hDk6A05hyrzJTtRqpkNBSVJf/b1zELh95OYkkZexY5cOmEg3f+d/uibpD qPyx2EKglVpWjb39xsmEdwsuinc8MzJriT27OXIAULBfOy8WbBlQOYW/p0Fas2ex93 45nT4YfraYg7SluCnxFjtrkKrSqCg6KebVNXzm/U= Message-ID: <55C363C2.2010005@cs.tcd.ie> Date: Thu, 06 Aug 2015 14:40:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Rene Struik , Hannes Tschofenig References: <55A6456E.4020806@gmx.net> <55C360B0.8070307@gmail.com> In-Reply-To: <55C360B0.8070307@gmail.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement? 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: Thu, 06 Aug 2015 13:40:25 -0000 On 06/08/15 14:27, Rene Struik wrote: > Hi Hannes: > > I do not think there is any technical or practical reason to add support > for ChaCha or Poly1305. > > For very constrained devices, the required state is quite large, > per-message key initialization cost is relatively high for short > message, allowing starting processing of incoming packets > after computation of those per-message keys only, and ChaCha20 keys are > 256-bits. Most underlying transceivers already have AES on board, in > hardware, and operate using 128-bit keys. Adding another mode does seem > to impose cost, with unclear technical benefit, both on security and > performance and implementation cost front. Sort-of. I've heard folks speculate that now that we're getting rid of rc4 this ciphersuite is a good one to use if one does not have AES h/w. And that seems reasonable to me. And were that reasonable, then it'd also likely result in having a ciphersuite in common between devices that do GCM and those that do CCM. So the possible upside here is twofold: 1) it's a reasonable ciphersuite for those who do not have AES h/w and 2) a way to provide interop between devices that have GCM h/w and devices that have CCM h/w. I would say that that is enough of an upside to argue for inclusion as a SHOULD-implement maybe. It would be reasonable though to say that it'd be better to wait a while until that ciphersuite is more widely used and to then update this profile. The downside there is that there's overhead in doing that and we might have missed the boat if we don't add that ciphersuite now. (Note: I'm not insisting on my preferred answer here, just that the question be discussed which is happening) S. > > On a side note: the security of Salsa20/20 has been quite well analyzed > (see, e.g., [1]), but - to my knowledge - this has not been extended to > ChaCha. > > Best regards, Rene > > [1] Ciphers - Salsa20 Secure Against Differential Cryptanalysis (Nicky > Mouha, Bart Preneel, IACR ePrint 2013-328) > > On 8/6/2015 6:00 AM, Hannes Tschofenig wrote: >> Hi all, Hi Stephen, >> I have sent the mail below to this mailing list in an attempt to >> solicit feedback from the DICE group after creating an issue in the >> issue tracker at http://trac.tools.ietf.org/wg/dice/trac/ticket/34 >> I have also posted a message to the CFRG list, see >> http://www.ietf.org/mail-archive/web/cfrg/current/msg07082.html >> While I got a little bit of feedback on the CFRG list I am still >> unsure about how to proceed on this topic. >> There does not seem to be strong interest in using ChaCha20 and Poly1305. >> Currently, AES is in used in hardware of many embedded/IoT systems. It >> is also mandated in various standards, including radio technologies. >> To my knowledge there is no hardware support for ChaCha20 and Poly1305 >> in chips today. >> Requiring ChaCha20 and Poly1305 in addition to AES would be possible >> on paper but will lead to additional flash space. >> What should we do? >> Ciao >> Hannes >> *Gesendet:* Mittwoch, 15. Juli 2015 um 13:35 Uhr >> *Von:* "Hannes Tschofenig" >> *An:* "dtls-iot@ietf.org" , "Stephen Farrell" >> >> *Betreff:* [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST >> implement? >> Stephen wrote: >> >> (11) 21: Why not make RFC7539 a SHOULD or MUST right now? Doesn't it >> seem like doing so now in a profile would be the right kind of timing? >> And that might be our best bet for healing the CCM/GCM rift so I'd like >> to check if the WG agree with that idea or not before we go to IETF LC. >> (That might justify a separate thread.) >> >> This is really a question for the group to think about. Any comments? >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot > From nobody Thu Aug 6 08:59:40 2015 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 57F7A1B3073 for ; Thu, 6 Aug 2015 08:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 RO5E6uInYUNu for ; Thu, 6 Aug 2015 08:59:37 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3AC1B303D for ; Thu, 6 Aug 2015 08:59:37 -0700 (PDT) Received: by ioeg141 with SMTP id g141so85573319ioe.3 for ; Thu, 06 Aug 2015 08:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Pq8Y7gHcuzGgFML5Elj8y7KrfLQvV2fP9JHsP8qeWLI=; b=SYdqpBGO/gGklVhu0tQIXFAAdxzTO1J9WJT7XciR7cnk7r9Y5rCCjuvIZaSPZr0jXB 2XGg4RVrZpOKSznzHwuvt7DUf/U4hFKfqgw415j0jRH+fTOcAVS0HxC27LFwKEoAL5lS ZCBxrB/khuvoYsAhgNSEp9xNYWtUUWSZxbryBftiWLZF9nf5QFX9mxcDIx2FxNGrryy7 RtgMLxu4u9DGkIhSus2EU5McpmpeSomw9MG3CV4+begYThEqX3YDq8+txO3zqKsfB4sV OA8QlHvKQAk6m7XSDaWM59K1xDXnGpwJ1zOQu1j+CnvyV7DokBGxJkh0tqFhcU7etQAX XChA== X-Received: by 10.107.13.72 with SMTP id 69mr3380105ion.182.1438876776763; Thu, 06 Aug 2015 08:59:36 -0700 (PDT) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by smtp.gmail.com with ESMTPSA id a6sm4784735ioj.1.2015.08.06.08.59.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 08:59:35 -0700 (PDT) To: Stephen Farrell , Hannes Tschofenig References: <55A6456E.4020806@gmx.net> <55C360B0.8070307@gmail.com> <55C363C2.2010005@cs.tcd.ie> From: Rene Struik Message-ID: <55C38452.9060304@gmail.com> Date: Thu, 6 Aug 2015 11:59:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55C363C2.2010005@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement? 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: Thu, 06 Aug 2015 15:59:39 -0000 Hi Stephen: I do not understand your reasoning, nor the relevance of RC4 (which is a stream cipher). I would like to understand a little bit more why you think this would be a good fit in the (almost empty) universe of constrained nodes that do not have AES hardware on board. Wha problem are you trying to solve?? Rene On 8/6/2015 9:40 AM, Stephen Farrell wrote: > > On 06/08/15 14:27, Rene Struik wrote: >> Hi Hannes: >> >> I do not think there is any technical or practical reason to add support >> for ChaCha or Poly1305. >> >> For very constrained devices, the required state is quite large, >> per-message key initialization cost is relatively high for short >> message, allowing starting processing of incoming packets >> after computation of those per-message keys only, and ChaCha20 keys are >> 256-bits. Most underlying transceivers already have AES on board, in >> hardware, and operate using 128-bit keys. Adding another mode does seem >> to impose cost, with unclear technical benefit, both on security and >> performance and implementation cost front. > Sort-of. I've heard folks speculate that now that we're getting > rid of rc4 this ciphersuite is a good one to use if one does not > have AES h/w. And that seems reasonable to me. And were that > reasonable, then it'd also likely result in having a ciphersuite > in common between devices that do GCM and those that do CCM. > > So the possible upside here is twofold: 1) it's a reasonable > ciphersuite for those who do not have AES h/w and 2) a way to > provide interop between devices that have GCM h/w and devices > that have CCM h/w. > > I would say that that is enough of an upside to argue for > inclusion as a SHOULD-implement maybe. > > It would be reasonable though to say that it'd be better to > wait a while until that ciphersuite is more widely used and to > then update this profile. The downside there is that there's > overhead in doing that and we might have missed the boat if > we don't add that ciphersuite now. > > (Note: I'm not insisting on my preferred answer here, just that > the question be discussed which is happening) > > S. > > >> On a side note: the security of Salsa20/20 has been quite well analyzed >> (see, e.g., [1]), but - to my knowledge - this has not been extended to >> ChaCha. >> >> Best regards, Rene >> >> [1] Ciphers - Salsa20 Secure Against Differential Cryptanalysis (Nicky >> Mouha, Bart Preneel, IACR ePrint 2013-328) >> >> On 8/6/2015 6:00 AM, Hannes Tschofenig wrote: >>> Hi all, Hi Stephen, >>> I have sent the mail below to this mailing list in an attempt to >>> solicit feedback from the DICE group after creating an issue in the >>> issue tracker at http://trac.tools.ietf.org/wg/dice/trac/ticket/34 >>> I have also posted a message to the CFRG list, see >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg07082.html >>> While I got a little bit of feedback on the CFRG list I am still >>> unsure about how to proceed on this topic. >>> There does not seem to be strong interest in using ChaCha20 and Poly1305. >>> Currently, AES is in used in hardware of many embedded/IoT systems. It >>> is also mandated in various standards, including radio technologies. >>> To my knowledge there is no hardware support for ChaCha20 and Poly1305 >>> in chips today. >>> Requiring ChaCha20 and Poly1305 in addition to AES would be possible >>> on paper but will lead to additional flash space. >>> What should we do? >>> Ciao >>> Hannes >>> *Gesendet:* Mittwoch, 15. Juli 2015 um 13:35 Uhr >>> *Von:* "Hannes Tschofenig" >>> *An:* "dtls-iot@ietf.org" , "Stephen Farrell" >>> >>> *Betreff:* [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST >>> implement? >>> Stephen wrote: >>> >>> (11) 21: Why not make RFC7539 a SHOULD or MUST right now? Doesn't it >>> seem like doing so now in a profile would be the right kind of timing? >>> And that might be our best bet for healing the CCM/GCM rift so I'd like >>> to check if the WG agree with that idea or not before we go to IETF LC. >>> (That might justify a separate thread.) >>> >>> This is really a question for the group to think about. Any comments? >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 From nobody Fri Aug 7 07:21:37 2015 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 79BED1B2DA3 for ; Fri, 7 Aug 2015 07:21:36 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axx2fCIFMrF4 for ; Fri, 7 Aug 2015 07:21:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E05B1A0358 for ; Fri, 7 Aug 2015 07:21:33 -0700 (PDT) Received: from [192.168.131.133] ([80.92.114.74]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LztHH-1Ykp343gp9-0154WM; Fri, 07 Aug 2015 16:21:30 +0200 Message-ID: <55C4BEE5.5080107@gmx.net> Date: Fri, 07 Aug 2015 16:21:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Michael StJohns , Stephen Farrell References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> <55C23E1B.5050300@cs.tcd.ie> <55C2687F.8050004@nthpermutation.com> In-Reply-To: <55C2687F.8050004@nthpermutation.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gk9X0VGthMOvJftVNU7iul254dewE8qLd" X-Provags-ID: V03:K0:4TZIft9UwYiVabH+0R1VOXyduIkwUhzyCaGv+DESqTLeWRz1d7n 1RMGT7Yi6xzXv6Lpwl+pgmFI+MGmZdEXWT8k3cCG9HGAJHqgZDytZB5u4hsdMVELIWu8+U1 fs+YovnPvtcPGftY0LS/KLy7b9U/p6eFO5GyxPkgk5hlIFjQEzfLGzLH+vUUC9kFjSb6pme WBNV4moIw6Ky8DFr8CaBA== X-UI-Out-Filterresults: notjunk:1;V01:K0:3bQnvA/fnqE=:0QHqkndXxpu+kbxy6W0C5/ 9wEouvRNQZfbtcPyYFicDC2VWw6nx6nYddearvCFQBLpAiiZhFpNfCX3F5qAjDl9JSl/DxWs2 +RWy2oWsTEQYdYrUFhb3XjoTtQ9mEicJgKvy7NhBCwXDe8qR6u3rMf0lQZDhRR6YmiuzcShtB t/450COeDl8s1Y1pn/EuLVBsGXU1RHMzvGxZjScWAU7RrubPByGJO604tXgXgOd84yrW8Fa1d Ex/SwDWJdNrVrsHq1UbKMVFwY4hUzpgs45/xillAr09jdCygcM3KyhxuTep4w+lEF55qSPsyd k2oVHonxld09EJSGABFzqhogBZtCym1a/eYlqQm3noJdvSbb6NiTDor+fMeG3RJvVoGfY7Nfk kv0yjQtW6jcRlZirjCLSeM2nUV9f89D2QIF6vntuoiM59o4syRc6PkTfhD44LFqPivZijl8Df vb3MDlDQhI5xfCBYo9G2FOUUrw5ANdC/XoRXUyndYxu69KwU0w910FphWPGS8mtSSlL7771Uh WZ/AsFc476h1dI74WHwEM0CmjcbJfUZpN0OXiTYrUZV0zaj2guZBQaxzUizhZffCKo7rJImp/ Ov66tUTmLsjFtgWvJw0IFDmo30BQco8Syfjk7TL+S8cjklk7RrYmushbIVCXMymWAVm4ag4fY 6iQ85BuCqu55smp47wHXZ8tH3puIH9AimEONZ5UenpCHOsYBwrAD6Z0RWODa552rvz/6u1RW+ lotafA4Bn2QlBHkD Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 07 Aug 2015 14:21:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gk9X0VGthMOvJftVNU7iul254dewE8qLd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, Hi Stephen, I don't understand why we should make any recommendations for how to use IP addresses in certificates. IP addresses in certificates are not useful for end devices since their IP addresses is most likely not known during manufacturing nor does it add any security value. Regarding IEEE 802.1AR I don't believe it recommends using IP addresses in certificates either. Ciao Hannes On 08/05/2015 09:48 PM, Michael StJohns wrote: > Hi Stephen et al. >=20 > I'm coming in on this fairly late (2 weeks) so let me try and muddy the= > waters: >=20 > IEEE 802.1AR is a good source for ideas of how to deal with certificate= s > and small devices. In the case of Zigbee Smart Energy 2.0 for example= , > we use their concepts of LDevID (Locally significant) and IDevID > (Initial) device identifiers. The latter is what gets built into the > device and SEP2.0 uses the SubjectAltName hardwareModuleName in RFC4108= > as the manufactured in name for the device. The attachment of a > certificate to MAC address or even IP address by the manufacturer has a= > number of issues that are painful to address and that don't usually add= > to the security of the system. (e.g. the handle of the name mostly > isn't important to the underlying protocols in IOT and the relationship= > between an entity and its IP or MAC generally isn't a necessary > consideration for trust between entities given certificates - same > reason that client certificates for TLS rarely have IP addresses in > them, but do have human personal names or email addresses). >=20 > Ideally you want a mapping between what's on the certificate inside the= > device and what's on the label outside - so that humans can basically > type things in (or barcode them or....) during installation. I might > expect a local trust center to issue an LDevID based on the (manual?) > acceptance of IDevID, and the LDevID *could* contain an IP address as a= > SubjectAltName, but I don't think we've gone that deep and most folk > balk at running a Mini-CA in their home. >=20 > So I think your recommendation of "future work needed" is probably more= > correct than "IP certificates needed". >=20 > Later, Mike >=20 >=20 >=20 >=20 >=20 > On 8/5/2015 12:47 PM, Stephen Farrell wrote: >> Hiya, >> >> On 05/08/15 15:54, Hannes Tschofenig wrote: >>> Hi Stephen, >>> reading through this issue again I believe you could help us further >>> explain >>> what we could recommend in the document. >> Assuming that it'd be a bunch of work to recommend how to best >> handle certificates for devices that will only ever have a bogon >> IP address, I guess the best for now is to just say that that work >> is not (yet) done and hence this document makes no recommendation. >> >> Seem ok? (And yes it could be that the current text on that >> is just fine, I didn't go look back right now) >> >> S. >> >>> Currently, we are saying that folks shouldn't use IP addresses in >>> certificates >>> and in the email below Thomas mentioned one reason for doing so. I >>> also pointed >>> to a separate draft we have been working on to explore the topic >>> further (see >>> ). >>> Ciao >>> Hannes >>> *Gesendet:* Dienstag, 21. Juli 2015 um 14:16 Uhr >>> *Von:* "FOSSATI, Thomas (Thomas)" = >>> *An:* "Stephen Farrell" , "Hannes Tschofen= ig" >>> , "dtls-iot@ietf.org" >>> *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates >>> Hi Stephen, >>> >>> On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell" >>> >>> wrote: >>> >Hiya, >>> > >>> >On 15/07/15 12:07, Hannes Tschofenig wrote: >>> >> Stephen wrote: >>> >> >>> >> (5) 6.3: Forgetting CoAP for the moment, surely this profile >>> will be >>> >> used with devices that only have (possibly bogon) IP addresses >>> and that >>> >> want to have those in certs. I do get that how to handle that >>> well is >>> >> not very clear, esp. for certs for e.g. 192.168.0.1, but >>> shouldn't it >>> >> really be covered by this profile? >>> > >>> >I should also have mentioned link-local addresses too I guess. >>> >>> v6 link-local make sense as stable identifiers, but they'd be equival= ent >>> to EUI-64 (which is what 6.3.2 requires for the use case where all th= e >>> secure communication happens on the same subnet), only a few bytes >>> larger >>> than their EUI counterpart. >>> >>> Other kinds of IP addresses aren't long-term/stable enough to be put >>> in a >>> certificate -- which is in line with the recommendation we give in Co= AP >>> [https://tools.ietf.org/html/rfc7252#section-9.1.3.3]. >>> >>> Cheers, t >>> >>> _______________________________________________ >>> 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 >> >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot --gk9X0VGthMOvJftVNU7iul254dewE8qLd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVxL7mAAoJEGhJURNOOiAtWqAIAIoMxH7y/O6q73GiUOAKjaMj 5U6DEtVRZKQPAf3iZqJeJ/MkjzmvmRw1YYQM6AMe4k6DARd+v1stmCSBXrKsaIhT o/XL2MLVAXBKkFz5u9C32ehYOVbQJKvffYDhW5S48Wz+9dRODtD2fkB5dGsrj0Dr N0y8hmdjcmfLKmyJD0/csNuGJb1ClqrlS3um1Hk9SYzWcJCVWR/lA77kSOsiIm/K 70m4t5duuIaC+ULyOTKYP7kTCbRMa0XcvP4MJV2zRvXCqhbnLkLuzvp1kjAvcfSI MvmUNT62QVG4Pa3s/SNOPZSNzDFBn5dQ7SnMEGfI/dj1LQgbZ+SmXhEiMZvJlrU= =W2d9 -----END PGP SIGNATURE----- --gk9X0VGthMOvJftVNU7iul254dewE8qLd-- From nobody Fri Aug 7 07:25:00 2015 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 606F91A0358 for ; Fri, 7 Aug 2015 07:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cuBQvy6IfcH for ; Fri, 7 Aug 2015 07:24:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7434E1B2DB1 for ; Fri, 7 Aug 2015 07:24:51 -0700 (PDT) Received: from [192.168.131.133] ([80.92.114.74]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0McVGq-1Z6Bir1Wz2-00HbpY; Fri, 07 Aug 2015 16:24:41 +0200 Message-ID: <55C4BFA1.1030600@gmx.net> Date: Fri, 07 Aug 2015 16:24:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Michael Richardson , Stephen Farrell References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie>, <55C23E1B.5050300@cs.tcd.ie> <22776.1438803665@sandelman.ca> In-Reply-To: <22776.1438803665@sandelman.ca> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="acnGnXrAiLq0idUnlAk3Dgj5lU7s3oSPI" X-Provags-ID: V03:K0:9B25BMEtRYhOOILS/F4J4xV4h/Z5ffg6IX6lN4k2mkVaHzxXvmt BBQQ15RwpIRSrDk5jh8zjnDlkfm00cIIMIu3UnPwywKjBxP01FKlxHrphFf0ncDI7ZSQqM9 ckyvYsAe3jtlSaXeOqVwHQbBSrKLUTSYh/xAlo31YK2yEkg3kvgO8C7vmAV86atuku5Boto jatnkpOLZtp1wWAtRUTQA== X-UI-Out-Filterresults: notjunk:1;V01:K0:766jWZ6kaRg=:gzlEtFIPVT3cuHyasF5SL9 MwVIkwR7Wox7FF8decRZwqBL4mXhSyXkKTUdyDYHu+ssqlMz6OVBmJVg/DoblFH247CUycvYf 1UBaFoKSztD3fAnsmzlOVpFU6sQ75EPQ6E7rsz/rPfOSJfu2Lmd/XbWuOl/wjjOsNj8a5lwCB m1I2zByR5JPITKzoYQ+HVIzQ5ols7/NaVTwhdfVMKPjiknAVAEyP6tsRQVo9I1EObqJKW+ScJ 6kR/tEMhJ3d3JDJv0/KS7CFxGWGCH0SHmEH5gECiRp3ViBKfefcWVwC+PLI5fgZRjQG8WZ39z UjmH8U7wHfgMA5PNO2CixEyNxE9+XABOlZEQIabBBqf04+H3xcSHeFQrpRPu+9DaClXfZwlDA kbIKF2uJbRyWnjLTvTR80q8Crm6NJ+fH0UpTIkmek2W3EKthKKUTAjFRTDpHZl5Fv/b7d+jXF b6NP85LQhG284+0IiZAyAMe1ujTE6lXzllKjVqgY5RW/5IIJdpfAJ4vZs0uVTge8gD7yPlprn rvuCQNmcQww9H6LnxftJBVP+fePBzZXdvGysytI5tmF3XZB9v6S3Ee08EktKb7MO2PlawwD1+ bKpua5iXciWHjrOH4HPjV+PgFQhdHqhwD3M4KuaVU/G5wmOlZRLmKMb64K/U/qRlqPS2bchfz wAZdRyXzh7Z7Dq7QEaG2acnir9reiayZTjSFQcMAsmVK1RpERy1Dzvo/URm3UPgWPLQ0UEvjZ okTw30YEceNPLiUR Archived-At: Cc: "FOSSATI, Thomas \(Thomas\)" , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 07 Aug 2015 14:24:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --acnGnXrAiLq0idUnlAk3Dgj5lU7s3oSPI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Michael, could you explain the idea behind draft-richardson-6tisch-idevid-cert? I don't see how it relates to Stephen's request to add a description on how to use IP addresses in certificates for the DTLS/TLS IoT profiles draft. Ciao Hannes On 08/05/2015 09:41 PM, Michael Richardson wrote: >=20 > Stephen Farrell wrote: > > On 05/08/15 15:54, Hannes Tschofenig wrote: > >> Hi Stephen, reading through this issue again I believe you could= help > >> us further explain what we could recommend in the document. >=20 > > Assuming that it'd be a bunch of work to recommend how to best ha= ndle > > certificates for devices that will only ever have a bogon IP addr= ess, I > > guess the best for now is to just say that that work is not (yet)= done > > and hence this document makes no recommendation. >=20 > > Seem ok? (And yes it could be that the current text on that is ju= st > > fine, I didn't go look back right now) >=20 > okay, but we need to do this work for ANIMA, and other places. >=20 > I wrote: > http://datatracker.ietf.org/doc/draft-richardson-6tisch-idevid-cert/ >=20 > But elsewhere in this thread I mentioned a current killer-app need for > this is with service processors (ILOM/iDRAC/...) which seldom have anyt= hing > other than a rfc1918 dhcp address, and really, the browser location bar= > should show the end user the vendor and mac address of the unit, not th= e IP > address. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 --acnGnXrAiLq0idUnlAk3Dgj5lU7s3oSPI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVxL+hAAoJEGhJURNOOiAtgkYIAIGLwxytKZSHEmjhfLN2OEdW 7HP8qy9L4eVAsom09M2Zk+OILjwpFYwdzoDLGdi5D87f0UOAH2Co3CVCZg9bA2j/ zH8QEtzNpUWXvt7xDADMKRScfOvUAQt9JhR5DEiZ5rPtXZpOBcfHIVjZTxAxatcf McPh0LUzRWPR0D7rqU6wAqd6YINncBItnkL3T80SOPGI8cNp406b9GmvUzdOnFPu HNSue+eaolgA/4zHbV0UUjP9t7t3O7hNpp4IeIoisabBYNJGj/xlM4OM8InGNd7H uQG42txdR90AZ/3NHfpHgfYXtO/I7PpPtjZ9zQ/F/T7TCBYb5QxZ/GQ2h5gax3g= =9U9R -----END PGP SIGNATURE----- --acnGnXrAiLq0idUnlAk3Dgj5lU7s3oSPI-- From nobody Fri Aug 7 08:42:39 2015 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 A80FB1B2E48 for ; Fri, 7 Aug 2015 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkCF3R5i5mPi for ; Fri, 7 Aug 2015 08:42:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83C81B2E5A for ; Fri, 7 Aug 2015 08:42:15 -0700 (PDT) Received: from [192.168.131.133] ([80.92.114.74]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MbOrg-1Z4yRe0sUe-00Iir6 for ; Fri, 07 Aug 2015 17:42:14 +0200 Message-ID: <55C4D1CE.6010802@gmx.net> Date: Fri, 07 Aug 2015 17:42:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lIt27JuBCETwU96XP3FFp3jwcBtHUCc9D" X-Provags-ID: V03:K0:8S60pAkataGY0xHJE4Kxmtcd5XrASXmiY7+F9RrhKumBY5uVuZQ n1iyVYCBmOggeNEZmZTE0/HocDl6egOdu+VnPenqSHvEPVYjtrTcAZWEjGEybhkWlGliwOf q2eAT1/5SNn0dBfoye63nc/XvY29MU6jX5lUZsGPbXFzckc19amIfxyAbZhJtB4CpjXS0yH VXOcs998LbLfjcPlNZpeQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:apqdod3LMBM=:u5WN0UsVRlCD6gvC23TDNv O6CK8fEkerldngbgUsJT7h2MYrttcTo0UdKcdW3qniy5+9ITz4cfgCWF6Sqt0f4bmhPZNKfhx kqFa8XLTWi4hVgYa2v0J3vHiaS75wpk2ULP+H6D/UlMTVaQux9tY0rkFsub95Sz13hjiujJPH Nrz9lDiy55Kql03/I4ZQzLASaflKLvF61V1RTrDkuoR2Hc4XtShEvF1/IrtgBgrLpogdKUauF c4mv3Adj2DPMAHkg9MewDVJoZ32I03vwlDndbpRlIVK5imeunuSPvpvGWLSOSxzwFPXg0aBXy p4swSgi2T09UHHs6uIUD7oWhZJA6BjEGRfpX4e/90bCH46Th1CRSCUSaGnTQXpUxL686pPm3q Gj+II8o3oxWvVZAIq0QwjaoS94sjk5Cy7engdaKUytDvt/Z7M3jlpAhWTaBUAlNXgrKJfkL+M U4tMxkSTZfKi+eTtbu6Lfev8ImNQsmm9zNKCKjn9TfOZXha6alOXKcE3rnztUbWcngyVtqGTg FXkgbiXCVdjtlJ9lw2mLs22f2FalxsKp4014pyoPAKlxY8Hv/NanaEEyL6TcaiCJaUQ6/PGVg qquVKGsjhRrLR1zbr3T3UqLsFih5HC6zS6hUXP/90d2VTHt3ZFD8RXSN8Jf3EcWB6agdH1Fvf N2Lfb7hW3dDLewR8W72CAc8jTaLWC+E+STgxSX+ORcxkGZ+8Sq2+lsCYNCnJqjMFjpmX1O+/F 68emiVROk/Ww/Iww Archived-At: Subject: [Dtls-iot] Secure Time (again) 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, 07 Aug 2015 15:42:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lIt27JuBCETwU96XP3FFp3jwcBtHUCc9D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I wanted to come back to ticket #31 and #32 about secure time http://trac.tools.ietf.org/wg/dice/trac/ticket/31 http://trac.tools.ietf.org/wg/dice/trac/ticket/32 Most IoT devices have no real-time clock and even if they have one it needs to be set at some point in time. Many security protocols, including DTLS/TLS rely on synchronized clocks. To check whether a certificate used during the TLS exchange is valid the expiry time needs to be verified. Other protocols also require synchronized clocks. For example, a protocol that uses tokens that contain an expiry time will require some form of synchronized clocks= =2E It turns out that TLS has a way to communicate time information from the server to the client as part of the ServerHello message. Of course, it is not a good idea to trust every server when they return time information since this allows an adversary to trick the client into accepting an expired certificate. It is, however, quite likely that an IoT device will be equipped with credentials that do not expire (for example those credentials provisioned during manufacturing) and those will only be used with dedicated entities, such as authorization / key distribution servers. Getting time information from those special servers without using yet another protocol (such as NTP) is obviously desired. Note that this is not a new idea. I have copied the relevant text from RFC 4120 (Kerberos) to the end of this mail. In a previous exchange Carsten (see http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00633.html) argued that the DTLS/TLS IoT profiles draft is a good place to write text about this functionality based on text in the TLS specification. The first question that arises whether we should use a time synchronization mechanism within TLS / DTLS or deal with this issue at an application layer protocol. If we define the functionality in TLS / DTLS we need to be aware of the recent decision by the TLS working group to remove the unix_time functionality from the ServerHello message. While this is not a problem for TLS / DTLS 1.2 it might be a problem in the future. So, what is your preference? Ciao Hannes ----------- Kerberos Time Synchronization Mechanism ----------------- " Upon validation of the KRB_AS_REP message (by checking the returned nonce against that sent in the KRB_AS_REQ message), the client knows that the current time on the KDC is that read from the authtime field of the encrypted part of the reply. The client can optionally use this value for clock synchronization in subsequent messages by recording with the ticket the difference (offset) between the authtime value and the local clock. This offset can then be used by the same user to adjust the time read from the system clock when generating messages [DGT96]. This technique MUST be used when adjusting for clock skew instead of directly changing the system clock, because the KDC reply is only authenticated to the user whose secret key was used, but not to the system or workstation. If the clock were adjusted, an attacker colluding with a user logging into a workstation could agree on a password, resulting in a KDC reply that would be correctly validated even though it did not originate from a KDC trusted by the workstation. " --lIt27JuBCETwU96XP3FFp3jwcBtHUCc9D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVxNHOAAoJEGhJURNOOiAtwnQH/3Yw+F4MH2BRi8DK2h7tmhpA Hlm0z5qvoUthpYergVaOiwVrZUFipmsZIUs8Ki8sau0QCQAoWmXvg6ltPgw2Lq+k iOkNEhOIbJfNZjQ1dCkLo0OflNz2/xPef64L4IYT1yLbtjCBpHU5asI4m1R/m4lG z3voHGnYM60kVJlUp59EMSW/xOZx2xQPP8/iYmBSclm4xu3undMI7mUrNjhixIYv 9tqyVt2J+ZcuFMvDCmQhCZdbKzftRjzovqa6FAAztdMi0H+LDnyszepeKESYkOIp k+iTFEyeIVyFGGP6U1TyDlGlnajZrrzHj3yXrhE9+wzLcY+KoB7s0WViMylypmA= =Uw++ -----END PGP SIGNATURE----- --lIt27JuBCETwU96XP3FFp3jwcBtHUCc9D-- From nobody Fri Aug 7 12:15:28 2015 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 B0F9E1A1AE1 for ; Fri, 7 Aug 2015 12:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJvZk-Uq2kMm for ; Fri, 7 Aug 2015 12:15:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226CA1A03A1 for ; Fri, 7 Aug 2015 12:15:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AE381E472; Fri, 7 Aug 2015 14:04:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BAAB563B10; Fri, 7 Aug 2015 13:47:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A687063AD9; Fri, 7 Aug 2015 13:47:07 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <55C4BFA1.1030600@gmx.net> References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie>, <55C23E1B.5050300@cs.tcd.ie> <22776.1438803665@sandelman.ca> <55C4BFA1.1030600@gmx.net> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "dtls-iot@ietf.org" , "FOSSATI, Thomas \(Thomas\)" , Stephen Farrell Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 07 Aug 2015 19:15:26 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > could you explain the idea behind draft-richardson-6tisch-idevid-cert? > I don't see how it relates to Stephen's request to add a description on > how to use IP addresses in certificates for the DTLS/TLS IoT profiles > draft. 1) I rather agree that putting IP addresses in certificates is not useful. 2) I would prefer to see manufacturer installed certificates with something else in them, such as 802.1AR with a clear serial number that would be replaced by an LDevID certificate during a bootstrap process. The idevid-cert document goes a step further and suggests how the device with the installed certificate will validate the peer that it interacts with in much the same way that RPKI has been setup. I would claim that this is actually more important than what's in the device. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVcTvG4CLcPvd0N1lAQJLUgf/fSyq16/+6WhGn0jDz6dQeD9WqDKhAM6L qJDkxd/1Q9mZjauetHYspXc8i6wkxFCYl/3f4uPC5no+gG17BqP+drZxpmQ1YRcH HcYoV53aw1nzhU0ZAtWCaIuSiinGlRqbmXllECjFpU0mWSI/quBIyrmeMgsIvR5B 4g3PfZR1JNAgr4TPDyeIj1G6N3WDjKSahEJ8YP1lSvSWivbFN1BrrLp8ApF93DI4 v9hepzKvbGfr28Gi+4BM00pi5bNbaC22RzdhRC78qOZdH4Vc/ZtTNkIzAjbGuWnH ecHP2Lonsi08qtth1biDIfb+fyPk3/1a7JwDSb4hMd4KIMQ81sKnYw== =qGkx -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 9 11:23:20 2015 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 9AD281B2DFB for ; Sun, 9 Aug 2015 11:23:11 -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 K0BEmQvHdlth for ; Sun, 9 Aug 2015 11:23:10 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779631B2DF0 for ; Sun, 9 Aug 2015 11:23:10 -0700 (PDT) Received: by qkbm65 with SMTP id m65so52108865qkb.2 for ; Sun, 09 Aug 2015 11:23:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=r55X9Kes+t2I60RQP5TSFqdAGlDdZPvXAPzSg4BnlHw=; b=MyRLpqB0MthzdXyWAQxj+8uXjQ4V1+OeOZtYkS7b4LHqoTRmWBu9Jk0/UVMjL0bGXC wkJwy7cC9IT4sBK/wrp9Z6dCipwVp4Sb4DbphdAwfAqm3Zdre8fCRzleoU5ZXkAiwLiy RcVTpirZfdJ0PyQkM1AlJdedCWbuTHVNt9Z+NwrR27Gz6mCHmVZPj6Ly1u+ywA8pZBGf eBykB8dmfgSKpvY5ANOZSjvHA//WtKLbpWFKTVA6BhXHBtfT769o9PPUvk6MOP78OJ8Q 3O8OWJnV/wTJX26/QIgvCW78p6jFH4ul+2gLaJl3VSluf7eQuRnP6fyxBtJ2CAYlCzP8 dxUg== X-Gm-Message-State: ALoCoQmLQMVJ9PKgdWq9UGDV/EZ/Zg9Lt2U3oZpnAunuUPP6c/GY5e32VcFM/iyEKpPiDSb7paGz X-Received: by 10.55.19.98 with SMTP id d95mr31398054qkh.71.1439144589477; Sun, 09 Aug 2015 11:23:09 -0700 (PDT) Received: from ?IPv6:2601:148:c000:1bb4:5878:8b5b:6b96:a48a? ([2601:148:c000:1bb4:5878:8b5b:6b96:a48a]) by smtp.gmail.com with ESMTPSA id h35sm5445613qkh.34.2015.08.09.11.23.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2015 11:23:08 -0700 (PDT) To: dtls-iot@ietf.org References: <55C4D1CE.6010802@gmx.net> From: Michael StJohns Message-ID: <55C79A90.5070900@nthpermutation.com> Date: Sun, 9 Aug 2015 14:23:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55C4D1CE.6010802@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dtls-iot] Secure Time (again) 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, 09 Aug 2015 18:23:11 -0000 On 8/7/2015 11:42 AM, Hannes Tschofenig wrote: > It turns out that TLS has a way to communicate time information from the > server to the client as part of the ServerHello message. Of course, it > is not a good idea to trust every server when they return time > information since this allows an adversary to trick the client into > accepting an expired certificate. I think this has been deprecated and removed for TLS1.3? Mike From nobody Sun Aug 9 18:02:33 2015 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 5352E1A1B40 for ; Sun, 9 Aug 2015 18:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ROCRvhbpSi9 for ; Sun, 9 Aug 2015 18:02:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6D11A1B3D for ; Sun, 9 Aug 2015 18:02:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6DC81BE4D; Mon, 10 Aug 2015 02:02:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QNddKxVxO5t; Mon, 10 Aug 2015 02:02:25 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2D786BE3E; Mon, 10 Aug 2015 02:02:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439168545; bh=03x5VcabWB3MG2vJo2ArcRiX7JodZy/D4oHoQmuVWpk=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=bUxofs1b9XLSe4gTKrTEPMjQf99jpeVk58KFlSKUxZZlwDnE81xh0TO4so9ucKpXE iQHkci+5fFBvYCW8CwuEODTSZz42+SAd8o3TZjRG0TYc4v8EkeY5ZpGRTdUYJGbqfy nvPT4Zm9t62QqBIw4i6n4Nrh/6HjnZE1YfokyJcM= Message-ID: <55C7F80B.5020501@cs.tcd.ie> Date: Mon, 10 Aug 2015 02:02:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Hannes Tschofenig , Michael StJohns References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> <55C23E1B.5050300@cs.tcd.ie> <55C2687F.8050004@nthpermutation.com> <55C4BEE5.5080107@gmx.net> In-Reply-To: <55C4BEE5.5080107@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UfC5wdtvJVniRMCUVEBfX2SKCsuifgKnS" Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 10 Aug 2015 01:02:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UfC5wdtvJVniRMCUVEBfX2SKCsuifgKnS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/08/15 15:21, Hannes Tschofenig wrote: > Hi Mike, Hi Stephen, >=20 > I don't understand why we should make any recommendations for how to us= e > IP addresses in certificates. For which definition of "we"? I guess it is maybe wrong to consider the DICE WG doing this, but my comment was really asking the question and not insisting on a given answer. > IP addresses in certificates are not useful for end devices since their= > IP addresses is most likely not known during manufacturing nor does it > add any security value. Fair point. OTOH, there will be devices whose only visible identifier is an IP address, right? If so, and if certificates/DTLS are to be of use with such devices... then what? I do think some variety of "we" ought try to address this problem. >=20 > Regarding IEEE 802.1AR I don't believe it recommends using IP addresses= > in certificates either. Which is entirely fine. There are definitely better ways of naming things than with addresses, esp relatively-scoped addresses. S. >=20 > Ciao > Hannes >=20 > On 08/05/2015 09:48 PM, Michael StJohns wrote: >> Hi Stephen et al. >> >> I'm coming in on this fairly late (2 weeks) so let me try and muddy th= e >> waters: >> >> IEEE 802.1AR is a good source for ideas of how to deal with certificat= es >> and small devices. In the case of Zigbee Smart Energy 2.0 for exampl= e, >> we use their concepts of LDevID (Locally significant) and IDevID >> (Initial) device identifiers. The latter is what gets built into the >> device and SEP2.0 uses the SubjectAltName hardwareModuleName in RFC410= 8 >> as the manufactured in name for the device. The attachment of a >> certificate to MAC address or even IP address by the manufacturer has = a >> number of issues that are painful to address and that don't usually ad= d >> to the security of the system. (e.g. the handle of the name mostly >> isn't important to the underlying protocols in IOT and the relationshi= p >> between an entity and its IP or MAC generally isn't a necessary >> consideration for trust between entities given certificates - same >> reason that client certificates for TLS rarely have IP addresses in >> them, but do have human personal names or email addresses). >> >> Ideally you want a mapping between what's on the certificate inside th= e >> device and what's on the label outside - so that humans can basically >> type things in (or barcode them or....) during installation. I might >> expect a local trust center to issue an LDevID based on the (manual?) >> acceptance of IDevID, and the LDevID *could* contain an IP address as = a >> SubjectAltName, but I don't think we've gone that deep and most folk >> balk at running a Mini-CA in their home. >> >> So I think your recommendation of "future work needed" is probably mor= e >> correct than "IP certificates needed". >> >> Later, Mike >> >> >> >> >> >> On 8/5/2015 12:47 PM, Stephen Farrell wrote: >>> Hiya, >>> >>> On 05/08/15 15:54, Hannes Tschofenig wrote: >>>> Hi Stephen, >>>> reading through this issue again I believe you could help us further= >>>> explain >>>> what we could recommend in the document. >>> Assuming that it'd be a bunch of work to recommend how to best >>> handle certificates for devices that will only ever have a bogon >>> IP address, I guess the best for now is to just say that that work >>> is not (yet) done and hence this document makes no recommendation. >>> >>> Seem ok? (And yes it could be that the current text on that >>> is just fine, I didn't go look back right now) >>> >>> S. >>> >>>> Currently, we are saying that folks shouldn't use IP addresses in >>>> certificates >>>> and in the email below Thomas mentioned one reason for doing so. I >>>> also pointed >>>> to a separate draft we have been working on to explore the topic >>>> further (see >>>> ). >>>> Ciao >>>> Hannes >>>> *Gesendet:* Dienstag, 21. Juli 2015 um 14:16 Uhr >>>> *Von:* "FOSSATI, Thomas (Thomas)" >>>> *An:* "Stephen Farrell" , "Hannes Tschofe= nig" >>>> , "dtls-iot@ietf.org" = >>>> *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates >>>> Hi Stephen, >>>> >>>> On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell" >>>> >>>> wrote: >>>> >Hiya, >>>> > >>>> >On 15/07/15 12:07, Hannes Tschofenig wrote: >>>> >> Stephen wrote: >>>> >> >>>> >> (5) 6.3: Forgetting CoAP for the moment, surely this profile >>>> will be >>>> >> used with devices that only have (possibly bogon) IP addresses >>>> and that >>>> >> want to have those in certs. I do get that how to handle that >>>> well is >>>> >> not very clear, esp. for certs for e.g. 192.168.0.1, but >>>> shouldn't it >>>> >> really be covered by this profile? >>>> > >>>> >I should also have mentioned link-local addresses too I guess. >>>> >>>> v6 link-local make sense as stable identifiers, but they'd be equiva= lent >>>> to EUI-64 (which is what 6.3.2 requires for the use case where all t= he >>>> secure communication happens on the same subnet), only a few bytes >>>> larger >>>> than their EUI counterpart. >>>> >>>> Other kinds of IP addresses aren't long-term/stable enough to be put= >>>> in a >>>> certificate -- which is in line with the recommendation we give in C= oAP >>>> [https://tools.ietf.org/html/rfc7252#section-9.1.3.3]. >>>> >>>> Cheers, t >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --UfC5wdtvJVniRMCUVEBfX2SKCsuifgKnS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVx/ggAAoJEC88hzaAX42igAgIAIZQgGx7DvxrTtgzluxiFHS1 p1AuJZyS6KX5iAHkK6/xsXvcmehzqJE11mn7HK/CWrqmsrgZ15NQWiv/6SFz9V2o Li7aWNjAV8sXGrvirY4cnzZkfnaJiB9WnxQZtMxuN0rMmAXFqaWhF52k9rZUPR6I +NcwW7nDJf8tbA+aJ+DtN/le+HncyLueKLOg4eEE+uFyc6Cq8SsJcpNmJloGz4il ECWXfP6ix4OFXE6CKseuwwZ242fcu3esMErK7J/T6K6SBr/rl7jsnelM3QfZNrL0 ohlMXBydh1IYZpLb5lH1ou0rlFFaCA5DpclWOaNRKnM5fzmW+btrsxygK2k0c7Q= =4RM2 -----END PGP SIGNATURE----- --UfC5wdtvJVniRMCUVEBfX2SKCsuifgKnS-- From nobody Tue Aug 11 03:34:34 2015 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 A4E481A802A for ; Tue, 11 Aug 2015 03:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWJVAF2gadME for ; Tue, 11 Aug 2015 03:34:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CCD1A8028 for ; Tue, 11 Aug 2015 03:34:31 -0700 (PDT) Received: from [192.168.131.134] ([80.92.114.74]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MEFIm-1Za9Ur0wLw-00FV9g; Tue, 11 Aug 2015 12:34:29 +0200 Message-ID: <55C9CFB4.5070702@gmx.net> Date: Tue, 11 Aug 2015 12:34:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Michael StJohns , dtls-iot@ietf.org References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> In-Reply-To: <55C79A90.5070900@nthpermutation.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mx9fmVtWbxWj7tKjLXX9FwoOp5aWORdFP" X-Provags-ID: V03:K0:EY/OvBlB1QWjiZFpBkkvdpivMIMGQ91n7SRo2FOwdTR3/MVrGOe Gsa+Q+ChO4un7lgjGK+FFzEaqjYF5LmA25CmtUwJtL09KDDBsul5DVHDqMFk0lIQ6E2AZ34 RM5zyprPmx1ctzlJAPzeC7p0hoG8XMd8qtarlOvbDXZ1euTDnGeV2OxFNxAuBuQ54wFZKQS 6zKLkll2HIK3M8P55cIoA== X-UI-Out-Filterresults: notjunk:1;V01:K0:NRkUc4EG4KY=:quPu+jVkWkldcsIkrF/tJw 5vESwbRP18khNfEpxr13fvKGkUtys6/UeLNDgE+6YxQLgS6oXBcp42Ylf0l3j8IdOdg+2nOcM ORERREUiLUo98RKIvrYy96VW2nfdsrQ6VNBZsvOhC6RvjzP4P5Kv11+MYNPWa/BaDkOA5S1zU /GnZicStpY7VjNb1vKbZru9G3Tda4naxVNXhUBGITPk57xwTnyqJ14kpxOPO396CYOs5nUVOB t/lC7QT/MFx/u6av8RpolYiTrsv65EmgmK/IM9wkLQN4elWvDPqtRfU+NcpPRYWiaCscybfsl ToK7rodCKQmxhgSDoEf8mmZl8qf/wzSx++7YnMjBWBVX9h19wI8CgPkB7Bfb8VXHZANehWzft oF2QyvObG7yPA8pxJHR9gGqv372r2KbCqeGvA93QG1+h17p5Od/3FmG8kfAVUAZf/k2oSbx+g EDDBoQrDYFF3UWdCdQViEkVK1OItNiSlSHyiGpULUuytZPbTMp8YlvtgR6DqGvTLSsrt53ydF qKWIj9f9BR70cLQX5d1N4otGGbvkgdZXZi5OvPF+RJcx3MW4O+IR6fmogUx5+JBNN2LfJW/DD W1R/16uElfYzJ/5YqECn4696VWBuQvMFiI1qLZj+Cif3GxiFeTk1YqULTChcvqznE79uldWWq r2zKgPpKQELwQ/de3nvzSSoNDihnuBBUFpnFndPAbnrS+/O4Q8IO3iTPVNtMRc7UNYv7637GH gdrrnGIbW09h4pMJ Archived-At: Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 10:34:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mx9fmVtWbxWj7tKjLXX9FwoOp5aWORdFP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, yes, there have been discussions about removing this server-provided time information in TLS 1.3. Although the current profiles focus on TLS 1.2 this might cause some problems in the future. Ciao Hannes On 08/09/2015 08:23 PM, Michael StJohns wrote: > On 8/7/2015 11:42 AM, Hannes Tschofenig wrote: >> It turns out that TLS has a way to communicate time information from t= he >> server to the client as part of the ServerHello message. Of course, it= >> is not a good idea to trust every server when they return time >> information since this allows an adversary to trick the client into >> accepting an expired certificate. >=20 > I think this has been deprecated and removed for TLS1.3? >=20 > Mike >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot --mx9fmVtWbxWj7tKjLXX9FwoOp5aWORdFP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVyc+0AAoJEGhJURNOOiAt53EIAJAOXctartgZy1Yc5v9QW9V0 hPLgjY9WwLA76ICKp82D1vfMS/A95DR0cVSUKwNmwMj22W7ceQgbDc+whkuu64S+ pLVxLio0dFcM534q1CQa57CpxqyWzCFq7AY1663O+tQKz4d4b1wAHCdoq/vbF+Ir LFWely3Wv7Nx6Me8qRHU1BsJBqybnQL3RsXD/O55/I1ZwVOrzsXfXAtkXiMjrkWT 2aurwiM+0Q7u0TzDRi0yGwcK7RgkyonNta5VfiMcUEuaxovPaOCl1DslriRXECGY 4jpegH0awne3Y8QqNDkUjFbpSrO6x+MPNE5Q4mT1XIK660q9aYA2OwgCNnxLtz4= =75Rj -----END PGP SIGNATURE----- --mx9fmVtWbxWj7tKjLXX9FwoOp5aWORdFP-- From nobody Tue Aug 11 03:43:24 2015 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 2BF051A86E3 for ; Tue, 11 Aug 2015 03:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI2LCgIfNckA for ; Tue, 11 Aug 2015 03:43:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5291A86DF for ; Tue, 11 Aug 2015 03:43:21 -0700 (PDT) Received: from [192.168.131.134] ([80.92.114.74]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MNO33-1ZR1m00MiP-006xOG; Tue, 11 Aug 2015 12:43:17 +0200 Message-ID: <55C9D1BC.70500@gmx.net> Date: Tue, 11 Aug 2015 12:43:08 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Stephen Farrell , Michael StJohns References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> <55C23E1B.5050300@cs.tcd.ie> <55C2687F.8050004@nthpermutation.com> <55C4BEE5.5080107@gmx.net> <55C7F80B.5020501@cs.tcd.ie> In-Reply-To: <55C7F80B.5020501@cs.tcd.ie> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w2jaURvvkuLo563aGhL4GgQ7SCcb6ak54" X-Provags-ID: V03:K0:WVHomJrhGfAzIXv4tZ+bnSYL/AGPODcC8tBp7MTubkumS2n0gxP QA2eXvuX05Y5WJNmKeNaaJKGejhpnqD5PuSoGsONYL9jTwLN18XeYWjvgnrHNOfcx7d64hr 429wIxfNiKmyb9snl/KLk3IY3f6qlOjDiALMqxOitxNv10uOkSYNbIWdSEtd5CDtk89ktmc Co3Lb8nXBO4MUZzZUEcMw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FLicKlGJu6g=:UrdlhE5ZOasxSRu55ozOap vPQIlwWg2Vpw6fkweBhoNAuW1yAFq68X17PFFT/mdWdJAKbyW46H65vUSL58u2FwhXpHOYNcd 10W9OTQtITbqu1oDSwVldQjcaSedlGdWvV0cynoCHMl1ZWHolg+XqDsIvGczJf46Yz1lvARzv qM5RhipW+MmyyayAtEnCTh8fc2pdoNuEpvOD9256lga/DtDFzf+I1HbtOBx54m7eECg6UfeU3 FlFPE3MotSBU7XaCVEcXTVhkiKAqJV+w2s0bqEP+uWil+7PHycyH5UEsgA30A6B/xClmAbMyN kpqCvNM7yi4XAHThM6WJMXePyUAoBD4dE4OgE359q7RW3R0vGsV4i4wD58p3cYkbOLPr2z57N 7JihKkLXwOe7/NNylpVcszzFmAFUZCZHzX+tJpvbtpcAZOlpat2brIgGbEioGbd4lt1S0gFzB l30A1Kh2S1iQiYQhH3+8eW2J+KDdwK4dUsrmpQxmWfvIQ/VJPq0Nwwwgy9353qGW3DzTvKU3H 781VsOUqknpmTcL1FnwzDgc2VpbkGifv+15zQXAyNJJlEBdSwaAHH1sO7SXXx/l8zlme7EVzP o9njDczfkot3FiFaH+D6RayqoLhYDKCNWNK1h9ZOnBn/SkTO9h87k7r1BIWiCXdrFm1/vcj5N aMp6qcGOVzodURhb201BFQsIStE2FEXxpavt3NNVIfkNlykURzFlmzqVVQUpcED5IeH9Auc4w EqouZxPEJ0eaADqC Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 11 Aug 2015 10:43:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w2jaURvvkuLo563aGhL4GgQ7SCcb6ak54 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen, > OTOH, there will be devices whose only visible identifier is an IP > address, right? If so, and if certificates/DTLS are to be of use with > such devices... then what? I do think some variety of "we" ought try > to address this problem. I don't think that there are devices that have no other identifiers than IP addresses. For example, if a device has a network interface it will also have a MAC address. There will also be an application sitting on top of the stack that might introduce identifiers. Even beacons have identifiers (although they are not identifying individual devices themselves). As a software / hardware engineer you will have to figure out what hardware components and what firmware you put on the device. As such, it is useful to think about these types of things early, which the document should be able to do. Ciao Hannes --w2jaURvvkuLo563aGhL4GgQ7SCcb6ak54 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVydG8AAoJEGhJURNOOiAtNAsH/ilozvSeDJTX6c4Z+KzfD2tD 3+hMcO1w2keZkPlglkFnysWDntCszA8g5rByGA2chP8wcOGKNdg+44QM6fMMVKX7 jSjqBTtK/a4P1PznAwNjFsCNdUd5LUjYxyBk36eRnLX8y5EVweNa3djC2ba7+luI WdnTrYYU4UOg0R3swkFswKp311VEXohL9RuvRhjeNj5ytNVEh4YLFh91Pd9dv7y2 KaSksk0iFTfDeocEt8l5ezn8/xO0SQfLxaKKUIBJiX87mZh0kxSJiRkGdDpFlCDU BA95W9stmezHMihPzyTGFx7fpnA5efF83bbSCcRxQquqaiogxFVPTXRspnjkp24= =Pl6Z -----END PGP SIGNATURE----- --w2jaURvvkuLo563aGhL4GgQ7SCcb6ak54-- From nobody Tue Aug 11 03:50:15 2015 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 25D0D1A8711 for ; Tue, 11 Aug 2015 03:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pAzI6v7tTnu for ; Tue, 11 Aug 2015 03:50:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957881A870F for ; Tue, 11 Aug 2015 03:50:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52E3BBE80; Tue, 11 Aug 2015 11:50:10 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMbZw2EB2zOx; Tue, 11 Aug 2015 11:50:10 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0F9A2BE8E; Tue, 11 Aug 2015 11:50:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439290210; bh=paU8+ZBZ/mcXkLQSvg/9aDPj39cbHMmhKk752lsss0I=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=XDXZCm/xZVpEgQ112oqsABJX5yQXTqV8t6zvbXb9UxFrRxOUHtzub8GikTm3/FPvY fr19XjHvbdJkjVMt/1VjyXHudBvMhuhAb4TmX94l2+8hDiYvA4RVGYTb2UkXxdE87c 9EwA3esoLitajFyMDJoD6PDT4BDofCy3PAEaZAh8= Message-ID: <55C9D35D.60307@cs.tcd.ie> Date: Tue, 11 Aug 2015 11:50:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Hannes Tschofenig , Michael StJohns References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> <55C23E1B.5050300@cs.tcd.ie> <55C2687F.8050004@nthpermutation.com> <55C4BEE5.5080107@gmx.net> <55C7F80B.5020501@cs.tcd.ie> <55C9D1BC.70500@gmx.net> In-Reply-To: <55C9D1BC.70500@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8ctB5xBXkghIQDGB4hPA5omEiKkmXatN5" Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 11 Aug 2015 10:50:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8ctB5xBXkghIQDGB4hPA5omEiKkmXatN5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/08/15 11:43, Hannes Tschofenig wrote: > Hi Stephen, >=20 >> OTOH, there will be devices whose only visible identifier is an IP >> address, right? If so, and if certificates/DTLS are to be of use with >> such devices... then what? I do think some variety of "we" ought try >> to address this problem. >=20 > I don't think that there are devices that have no other identifiers tha= n > IP addresses. For example, if a device has a network interface it will > also have a MAC address.=20 My hope is that 802 move more and more towards non-static or random MAC addresses. > There will also be an application sitting on > top of the stack that might introduce identifiers. Sure, they "might" :-) And if they do, then for sure there shouldn't be any reason to put an IP address for such a device in a certificate. My point is that there will be devices where the IP address is the only reliably-present publicly (maybe public=3D=3Don-LAN here) visible identifier and where we'd like to use (D)TLS to talk to that device. And we have no guidance for that case, and we do have a bunch of gotchas and pitfalls. >=20 > Even beacons have identifiers (although they are not identifying > individual devices themselves). >=20 > As a software / hardware engineer you will have to figure out what > hardware components and what firmware you put on the device. As such, i= t > is useful to think about these types of things early, which the documen= t > should be able to do. Again, I'm not saying this document ought say what to do about a certificate for 10.0.0.1. But again "we" probably should think about that for some definition of "we" that is a subset of the IETF I reckon. (Unless someone else has done a good job already in which case that's fine.) S. >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --8ctB5xBXkghIQDGB4hPA5omEiKkmXatN5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVydNhAAoJEC88hzaAX42iO+0IAI1wRY6vO4H+VuVptQ3zrDWt JrLBrOY3L9fAeStb7/awUmBpMsWHOs+GrqJXtgv8nVO9x6XZoYdbDAuTqhVf6FrT 73fGJD2lYf4Wj7bqjaR15EqPefaaJc9aCYOofclXlOhTJGIGaRQgKxqi5NZOr40Y cpGFt9Q/ur47c86UhmgEAd8kP75DGxa6h8sqgTA1LsMyYuAWRmnelYVZxSWLygFU dj/L1tQrHVlydBELgw39pgAjT3PuLlmQ7oUN2s0eVZVCCk2cKhHE5NXeYHLuHvBC 3yiRQJya2GpXmYeFnhQnxNOKDbQ2s8/26FmOtKqebsrQUqmof3aGP1e/0W/7Vew= =bhIT -----END PGP SIGNATURE----- --8ctB5xBXkghIQDGB4hPA5omEiKkmXatN5-- From nobody Tue Aug 11 04:24:06 2015 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 B3F6D1A879E for ; Tue, 11 Aug 2015 04:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qJMk366EVbZ for ; Tue, 11 Aug 2015 04:24:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBE31A8706 for ; Tue, 11 Aug 2015 04:24:03 -0700 (PDT) Received: from [192.168.131.134] ([80.92.114.74]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MSuYT-1ZH7Ih0fmX-00Rpbw; Tue, 11 Aug 2015 13:23:58 +0200 Message-ID: <55C9DB23.1040308@gmx.net> Date: Tue, 11 Aug 2015 13:23:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Stephen Farrell , Michael StJohns References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> <55C23E1B.5050300@cs.tcd.ie> <55C2687F.8050004@nthpermutation.com> <55C4BEE5.5080107@gmx.net> <55C7F80B.5020501@cs.tcd.ie> <55C9D1BC.70500@gmx.net> <55C9D35D.60307@cs.tcd.ie> In-Reply-To: <55C9D35D.60307@cs.tcd.ie> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LBnpVaR6G2fmf6ABtnakdVoV9SgIm8Aoe" X-Provags-ID: V03:K0:r6548o3Zzavu4fUVFrR/DYZuuF2/h/JsIr/FldWNaOaCGEj3AIP q92Xy0BVlJmSCNREYdx7uLD0MFEA6hoKsXEJuDZekUWcxLGV22ZZenbMHLpXZ2RLXr0VPtm UmWaL150Glid4QQ41clsmZ6quwZkKwTWapIXoCT1iLF+VFFoINYmngHxrEoPRjPHPU6dSDA GC7SYFzBDPWIO2u/TXP/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:3fM4zqgXjwQ=:QCIsBWKWDfD1I2Nnq0jAFU SbNJwXMu06r3yCsOUVm9ZQ0kWAlMagiVtz9+b2dFlDbzRiPw5XmoQripntWRUeiDIPDLdnBPb fb/gaGteD02xIZyQdotdOyjeEJM5s4Ybp+10iChoOTOG+oMILzwgl+jFuAiO6WPkplLMQ60bT dubiZBQLC6X22snAZeuzkPDlCRWWLuDS5lI5Q+p3E8FVpnsNJjxrXkLChtU4yLNnfu6bbFBwm uwpIdFefItcnK0tRasasvEUkSWVCpls/dyP36tYT1+HJP/kBGsvNOtBvrhbta2Y0YE0SDBgSc +xkI5yrZhp9gRocxanXJjv6bQPLDeCMpG+oeuhCarHcDrseDGReWs+p8WuPe7Sn57K3h/yoJG nfXt5mfOkyvUMqFYxMONYq6xJJ/1HmZyIkYS/jLfWxLQwiVzMk6oYRfsTFV51An7KaCBziNmV IE4T5GnAIwSKzcjWxluwkraPPjL1biutUpTol4RC09Cb0jRRRjNAxexsTDQxKOvj38W6SzDys LZhKN7wCGgv+igt1NFAHI2gWFdYAMVoy7yTNdLOn889W7rjAF6wwhy5uE6Nc3NoesEatluRWu 1hPnVEc4PuwPFHQ18MMRkHJwzf38/akhHQ4zL+V07+GRT9+hRnR+rWgjLsL6s4ZcgurXmUd9Y z/Z69hskNVZauz51u1yEZiUgkubnELj2TwsURNR7FN8CmhSgff2LNHUFvABk6bDOIz8yx3lTG KXkD4gdQZMw/5duk Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 11 Aug 2015 11:24:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LBnpVaR6G2fmf6ABtnakdVoV9SgIm8Aoe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, On 08/11/2015 12:50 PM, Stephen Farrell wrote: >=20 >=20 > On 11/08/15 11:43, Hannes Tschofenig wrote: >> Hi Stephen, >> >>> OTOH, there will be devices whose only visible identifier is an IP >>> address, right? If so, and if certificates/DTLS are to be of use with= >>> such devices... then what? I do think some variety of "we" ought try >>> to address this problem. >> >> I don't think that there are devices that have no other identifiers th= an >> IP addresses. For example, if a device has a network interface it will= >> also have a MAC address.=20 >=20 > My hope is that 802 move more and more towards non-static or random > MAC addresses. Me too but then we (in the IETF) just replace it with something static at the IP layer (as we managed to remove the randomized IPv6 interface generation via 6lo....). >=20 >> There will also be an application sitting on >> top of the stack that might introduce identifiers. >=20 > Sure, they "might" :-) And if they do, then for sure there shouldn't > be any reason to put an IP address for such a device in a certificate. >=20 > My point is that there will be devices where the IP address is the > only reliably-present publicly (maybe public=3D=3Don-LAN here) visible > identifier and where we'd like to use (D)TLS to talk to that device. > And we have no guidance for that case, and we do have a bunch of > gotchas and pitfalls. Here is the additional challenges: 1) When are the certificates generated? 2) When are the IP address assignment happens? If the certificates are generated during the manufacturing time then the IP address cannot be know. So, what IP address are you going to put in there? May I assume that the certificate enrolment request is done using some protocol during the deployment (such as with EST) then the IoT devices provides the currently assigned IP address to the enrolment server to get the certificate back? Would this mean that every time the IoT device gets a new IP address it has to request a new certificate? If not, would we just assume that the IP address in the certificate has no relationship to what is contained in the certificate? If we talk about IPv6 addresses why wouldn't we just put the IID into the certificate rather than the full IP address (assuming that the IID does not change for certain deployments)? Ciao Hannes --LBnpVaR6G2fmf6ABtnakdVoV9SgIm8Aoe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVydsjAAoJEGhJURNOOiAtVdkH/3WDREIuC/672YBCescjwgI3 VUIoRGaEYc06SdkbQ0e1ze1uvvT5Afe7i2H+GKpi3hljjmG8PEK7Jw8g1LFslAB1 HmJEf+++WYS0eVe6ZxLeioHFAyEewLUhC2y9M7ts6DhlDb26nSMDVjHsb9zPkJIR Rl5poBQoEDXEEVAyJwgV5f7eo7M1+LiPxGCPJvIL00tYCKnFvaSiLH0V9WnK2Fs3 jjUuARrlrVaF1zsBAgJysqX2F+PP1I1WVJPXVmiSSifUDkYZG1O2yyJSRv48y14C j6TsX0qwQn2ZSccDGW4Y6psBgoIEtPQERyog9+avxPk85IL99PHOxr67gbvIfjQ= =Fz0+ -----END PGP SIGNATURE----- --LBnpVaR6G2fmf6ABtnakdVoV9SgIm8Aoe-- From nobody Tue Aug 11 06:34:25 2015 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 1A36D1A8A8B for ; Tue, 11 Aug 2015 06:34:24 -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 RYsmWZbF10_n for ; Tue, 11 Aug 2015 06:34:22 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014371A8A86 for ; Tue, 11 Aug 2015 06:34:21 -0700 (PDT) Received: by wicne3 with SMTP id ne3so61102252wic.0 for ; Tue, 11 Aug 2015 06:34:19 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9QTqkjD0m4P//Es0T6ZdOl3Ej6LHdOWkHaYXxYj6djE=; b=VyFhEHe/SiZu4OKazDcEQDRmfbwOw+BGKoS7wnZsExgr1i5jO7YqsegNyAmxzaO8IP kuyMYNKUrxMN84q/Piub1UxirGgVdVo2u0lDe5t4QdVdA91zchxtENlE5TaoZ26VSF7B +U/JxJFKO9lW76mjcamd7GbJKQ6MJMvrzfNnlwPdsyqzhFKLpYfXzggWPJwxKfQeVycd Aqg+rTXJZmRc7yYVKEQkEwJwnuCzCzrx/lhYzTvWG+3BMEkFFnKJ4rxsUuOATImzFAR3 cZvchaMH4V5F9FUZ8WDfGM4FApZKSJPbraeIhoTRKbTYGIz6DrcHYdU4899NY42BdspQ VtYA== X-Gm-Message-State: ALoCoQlXEkDSsl1xoiSJCiF4B1fqdlskw349u7L8KZw0vBLaYh2A9jfFk1+C+A1F8T5FDzMUgPIQ X-Received: by 10.180.85.233 with SMTP id k9mr14509556wiz.53.1439300059757; Tue, 11 Aug 2015 06:34:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.99 with HTTP; Tue, 11 Aug 2015 06:33:40 -0700 (PDT) In-Reply-To: <55C9CFB4.5070702@gmx.net> References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net> From: Eric Rescorla Date: Tue, 11 Aug 2015 08:33:40 -0500 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=f46d04447e39c99601051d0928e7 Archived-At: Cc: dtls-iot@ietf.org, Michael StJohns Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 13:34:24 -0000 --f46d04447e39c99601051d0928e7 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 5:34 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Mike, > > yes, there have been discussions about removing this server-provided > time information in TLS 1.3. > This is already done. -Ekr > Although the current profiles focus on TLS 1.2 this might cause some > problems in the future. > > Ciao > Hannes > > > On 08/09/2015 08:23 PM, Michael StJohns wrote: > > On 8/7/2015 11:42 AM, Hannes Tschofenig wrote: > >> It turns out that TLS has a way to communicate time information from the > >> server to the client as part of the ServerHello message. Of course, it > >> is not a good idea to trust every server when they return time > >> information since this allows an adversary to trick the client into > >> accepting an expired certificate. > > > > I think this has been deprecated and removed for TLS1.3? > > > > Mike > > > > _______________________________________________ > > 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 > > --f46d04447e39c99601051d0928e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 11, 2015 at 5:34 AM, Hannes Tschofenig <hannes.tschofenig@= gmx.net> wrote:
Hi Mike,
yes, there have been discussions about removing this server-provided
time information in TLS 1.3.

This is al= ready done.

-Ekr


=C2=A0
Although the current profiles focus on TLS 1.2 this might cause some
problems in the future.

Ciao
Hannes


On 08/09/2015 08:23 PM, Michael StJohns wrote:
> On 8/7/2015 11:42 AM, Hannes Tschofenig wrote:
>> It turns out that TLS has a way to communicate time information fr= om the
>> server to the client as part of the ServerHello message. Of course= , it
>> is not a good idea to trust every server when they return time
>> information since this allows an adversary to trick the client int= o
>> accepting an expired certificate.
>
> I think this has been deprecated and removed for TLS1.3?
>
> Mike
>
> _______________________________________________
> 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


--f46d04447e39c99601051d0928e7-- From nobody Tue Aug 11 07:28:48 2015 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 8A58F1A8AFA for ; Tue, 11 Aug 2015 07:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HA1Rfdx3wlo for ; Tue, 11 Aug 2015 07:28:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A07A1A8AF6 for ; Tue, 11 Aug 2015 07:28:45 -0700 (PDT) Received: from [192.168.131.134] ([80.92.114.74]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MKYLf-1ZPzMD0oDP-0020Jb; Tue, 11 Aug 2015 16:28:42 +0200 Message-ID: <55CA0692.9000509@gmx.net> Date: Tue, 11 Aug 2015 16:28:34 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Eric Rescorla References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IP11kMQ1xWF9ijaB1gJL6ng5HjrLpOdGF" X-Provags-ID: V03:K0:TaoFliH0XofKruWdlAM9WLoc2/LrEaRzy8ako2DOdTpgNIjr6eO L6I51dibMoY4b7Sism6ZQCQsFrS4gv3NbVgZXHva9JglE3AW/Y79J+mlO7DjGsSSRnCazrr zvDOcHps1UQ7Sa4rNr3XieQtx7U7jEH/yfrKoxrAC/LYMsozmjJr9LGhX1yY32OqCObOubF MohVtlJDuC1All6HUh5lQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ULeVqKaYIzI=:iTV5Ol2bxAZm9W6+a32hgR /CVLcviKDpB0bRgq3sfArwLY17siYo14OMqazV+2MTe5ZWqJxF1743IVPTelBUXUO2G7SkfrN GbRJwxuWRnCqWuIhY1NxC17zn0myPzPxRH/fQ5yQC54mkLnHyzs76vgpzbCjocrIKHAglZbfe 1OeVD7fy7uSWXeJ3ZPjjprUGA2cEoEW1b4pDmmXaW5Iifdbapx9GFnfnBAMGt20/yLOTa9Ec0 xxY5tGcNPHJ2Ce6XBy08ayVtj+mVTZ8jxU4h4LGicbG8Pr55ei8kl146Nk4fxyeVHXGABESt4 0Pbj+HpIbPyHZVn4uwhgpc8ZIBAD0dZHCxI7qhvYJhIFAJcS36bKJSzO5j3ZKuBbwhI/3Lpor ZGsfNVDItty56gdOszuqxT0MZQwuhM4wGay5yFl+bkZ8dn7SNCBMppEXBxykwNsCnJWlSN1xi nfIchVzmkZ8HO7AA8O9npD0irLcI2Zno5Ni1uknA6PElmciZmGW3XLKgXmh+jVy6YHRZySjba JxzmPq2Kn+OAm0y3SkQvXriEBAA3hfhvzEsvCkQcfbGmWfC7y+8mO8Cmsiks/ZgB7SSjFbUQS 3+wxM853ZhEJQJh5J7H0BkpFCXxhwxsMczL86/xHthsTjCexkii1nL+NynnW6SBEOPuqpCoRa XM1ei9kvDIoaArQNfT0gpHE7iAuPWo7ssflZuDcwvSoUe+o2fvmAMf/J+2kh29YPs2lX+ouy8 9s9qYMdZcT84sW8h Archived-At: Cc: dtls-iot@ietf.org, Michael StJohns Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 14:28:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IP11kMQ1xWF9ijaB1gJL6ng5HjrLpOdGF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, Ekr. On 08/11/2015 03:33 PM, Eric Rescorla wrote: > This is already done. While I understand the reason for removing the functionality from the ServerHello I still think it is a needed functionality for many IoT deployments to obtain time information (without having to fall back to NT= P). --IP11kMQ1xWF9ijaB1gJL6ng5HjrLpOdGF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVygaSAAoJEGhJURNOOiAtRoUH/jGd+8P2xeYkZI1/Usrg3Ai5 H7SK1YyJFjHbNeERKEwgbpRxtnJ1GxS++wuokgXqRghj2BZfX71J4y1YDlXNq9eK JOQEZfukbThBLZIL3IW3Rj9F/qLN60X62ArgZBQ7s47WdU/paWYYeUuJ8I/M7q38 hhHhfI2xQHKryEyE37w5lXdLtHkGwfrN7P2s8ZZRQi9LJMwgCex5BOSMV0sew0S4 51OB54TpM+Ar9eNcN/gDN2bn5UANw+6IBDOPTaFPRgSevyTPYdpvpSkRKwFWqtyr m+ejl0jSzvKaFa8NHuTGohToQ9z5i4QDNsNcASDHxcXIc2kNXgJwrivkX9rsdZE= =ePed -----END PGP SIGNATURE----- --IP11kMQ1xWF9ijaB1gJL6ng5HjrLpOdGF-- From nobody Tue Aug 11 07:35:33 2015 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 8A4771A8F38 for ; Tue, 11 Aug 2015 07:35:32 -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 46HFp_1G6W7g for ; Tue, 11 Aug 2015 07:35:31 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6E11A8BC5 for ; Tue, 11 Aug 2015 07:35:30 -0700 (PDT) Received: by qgeg42 with SMTP id g42so104189211qge.1 for ; Tue, 11 Aug 2015 07:35:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=PYn67P237ML/RG+y/UAL1uewVeVP/lDrNc+z86ufXw8=; b=GL7k8xkgG2B3o7FhPCjYKrzwD/ztuorglgmQcq9e/FQIksoQe9HA29fPDqOuHtEd/L AgtySdHobssmeGbmP5hDJn5w4GIbj2KxhlgxlmxEkyOm8T7v32N7KmSBmyDHf/NWr+bA jeuVgiRHvNNwMbfga0xDvlPKkhfhXW/1f0jh1Ejq9GKUcERET0wvWoE5Q9G1P4dbppNJ PaU0/+q42otVv2MuVRN1E4egWvu1397ZzzmMgz8TijotHB9g7Y6Q4C8LcVj/mng1t4FY 3OO6NIqZ1CExDtEt4EKTovPU55JPbKUQg2pyx2ajy42X+RNh/L1hK/xGy4wtqFgMZ2Rg 3uyA== X-Gm-Message-State: ALoCoQnQj94uqwt/L7qtbxDn4szhs8SFqZHmmJRDU0o2HBXv78Wh0VEnkg0oYgmEHXhDcbqcTq4N X-Received: by 10.140.194.198 with SMTP id p189mr51683751qha.42.1439303729977; Tue, 11 Aug 2015 07:35:29 -0700 (PDT) Received: from ?IPv6:2601:148:c000:1bb4:25a8:b49c:958b:8d09? ([2601:148:c000:1bb4:25a8:b49c:958b:8d09]) by smtp.gmail.com with ESMTPSA id 76sm1276101qgf.7.2015.08.11.07.35.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 07:35:29 -0700 (PDT) To: Hannes Tschofenig , Eric Rescorla References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net> <55CA0692.9000509@gmx.net> From: Michael StJohns Message-ID: <55CA0837.5050008@nthpermutation.com> Date: Tue, 11 Aug 2015 10:35:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55CA0692.9000509@gmx.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 14:35:32 -0000 On 8/11/2015 10:28 AM, Hannes Tschofenig wrote: > Thanks, Ekr. > > On 08/11/2015 03:33 PM, Eric Rescorla wrote: >> This is already done. > While I understand the reason for removing the functionality from the > ServerHello I still think it is a needed functionality for many IoT > deployments to obtain time information (without having to fall back to NTP). > Yup - but not all IOT devices will do DTLS or TLS. And time in DTLS or TLS isn't "secure". I think for this version, you should assume that DTLS and TLS will not be a source of time and write accordingly. Mike From nobody Tue Aug 11 07:40:41 2015 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 CCFB61A8F46 for ; Tue, 11 Aug 2015 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0kzOqe9aTKn for ; Tue, 11 Aug 2015 07:40:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CA71A8BBF for ; Tue, 11 Aug 2015 07:40:37 -0700 (PDT) Received: from [192.168.131.134] ([80.92.114.74]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MPqtK-1ZT2cF2mYc-0051Ob; Tue, 11 Aug 2015 16:40:33 +0200 Message-ID: <55CA0950.9050305@gmx.net> Date: Tue, 11 Aug 2015 16:40:16 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Michael StJohns , Eric Rescorla References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net> <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> In-Reply-To: <55CA0837.5050008@nthpermutation.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3j8cvJ60n0TEvpr0RvKWgp3Cv26MVGVfN" X-Provags-ID: V03:K0:8kMpCDmWiB8SNwlZSlj1US8ASOttq/i/2W6ewZtnXIOSm//+Lni dlGLaS+7OByn7InZml6HpSz/xxRceU4Rs74JOQHfTtKtu7wEYyN/VKw7gm6XXzjTL8D+zSv Az6n0pZk6C2cGXY3buRfjnR7vFN0C4BHFN9ID/pm6E4/9P1+VnJqEOM58QFI9fn7e9i+8fp yvFA8YdysZ2Kio9BUMHtg== X-UI-Out-Filterresults: notjunk:1;V01:K0:N/RFC17ydEw=:/dHsLBt4nCPixTWHEHi+ig Nx/o8hp+tqCJabuYQo91DnW6gwkfrDxCOnRNR0P+1WKO315puZlSgGSp++sjA8K3AaWkvBkBk 1kZerhxxNp7B7+xLzBv05e5CTaOUQjfqrF4IxJxXTBoF2k+T3nYmSUuaV3bi1wO1Pn/kxvR7/ DnGIfbIRlU0ULcas06oHlrniku9f63/Ge3oGLht2jGTD28Rd5xYH6JSXcXHC7vZUwfQ5kTxjv B+pMjiUENoyOhRY0juIgoL4lbScEig65aVfdJOjCKZ5/vjpC5PODENh1uVSIXnecOnVTzFdjT V5tU0p3DyEOZkggcHqRpPjGpN/5ed4jCPq5dBiCl62tw+sR54W1kzNJms9nm3a4Lpa+/C3wh8 /txzPOvhVVBRfEqrtpGJGC7+LIA0cOh9HvsMbC1PCiJ2Y283gzUjeVLLr11TQfxbI1B54l2DP mNhkAi5sM6lsPvzUiWZugZ7bK+7PZf+wZ6TMM3wRRK+Djj7+a3zi/Mte7bAJyJG7fuNBp8NOQ uPuQ+dnDmr8q2C7jM5AY7+WXwD1bKf5+zxz1E8fEDc/q9vFKWCGlYitHJbaoaECKpjH2vseZ5 L+qxZl+RibC/dZ3YSpaGEMRX3gI7+9i/4lvBqjZ+1kJ3XE4WDW7ax5JaGMeygeHg8jm5taQ9N TB3aCY/B9L0OY1v1peejktjGuOSSn1NX7U9epTHgRSoqMx8LRkU9VGAasEDSxCN7i1JF0LNyj VKET6BLV31edSV1m Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 14:40:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3j8cvJ60n0TEvpr0RvKWgp3Cv26MVGVfN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Yup - but not all IOT devices will do DTLS or TLS. And time in DTLS or= > TLS isn't "secure". >=20 > I think for this version, you should assume that DTLS and TLS will not > be a source of time and write accordingly. That's fair! --3j8cvJ60n0TEvpr0RvKWgp3Cv26MVGVfN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVyglQAAoJEGhJURNOOiAt52IH/16GQ95X573bf9FO5wCx4YxD 1uXRSIavHbHcj5OTbs73Ce2a0IwksbV/GCYbuYCYSgv6/zrVLVJk/g2OUxK1yRez SLFRCLmjqLT7lxF0S9SnmWSK4LexZCixeOqmEc3sqKms0dxV1dN76248mID6gFXi oeShixRtpVl/0pTcXs8aMUK5bg9joGSggGLM4sTICS4GHRq8ioC84lLeHv/rRm4e Kql5nry1+WzkdHJ/o1mmjf/TiXehqrxk0waik4hkjVp3fUgOs179/lyG2j6NvLOA GlxylKHfg9cGgNPXkW2b4Oi+AMYJ7kfg7N4+idR59HNMGoiy5O54a0qsgnexUNU= =dUkp -----END PGP SIGNATURE----- --3j8cvJ60n0TEvpr0RvKWgp3Cv26MVGVfN-- From nobody Tue Aug 11 07:44:57 2015 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 35EE91A8F50 for ; Tue, 11 Aug 2015 07:44:56 -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 YWTtd1uTL7uX for ; Tue, 11 Aug 2015 07:44:54 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE29F1A8A97 for ; Tue, 11 Aug 2015 07:44:53 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so20092189lbc.2 for ; Tue, 11 Aug 2015 07:44:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=nmyugaTJDLc3Umz/GzwGzI7Ye+K2SEDWX+OsnT97ukg=; b=IQhBJMTgvxUgwWqyeCQnTqK4f7mhDl3C+WFhQPhDnEfXg9wGQkWlU+S+iKvOTFGKSC 4z/tI76w++5z/e0CuDsrXYFyJ/aU4xSaW7qxs0T2lIsMeEptGkbINg/MsCkXM1Lcmdb0 LGgDt/InfgE1tXdKD5MwLUeEm5DuIIiRcj8jMRclOzC/6uKd2/mHlOfV9Z4ARSkmRXH3 MHPCBQtXejgG5QXuh9iSvaBL8qPbQwON1sDtOD1gAhCZjTU3Jkwwga9EOtyKchyfx7RH 6ZcEg0hVjJIP77KdnFPjRoCA9zuzeIcT0UNeSS2dKUzNwZRN6IHbPWd/vazaVOCGPh+0 WxWw== X-Gm-Message-State: ALoCoQmcv9CTlB96lc54iYTR+KlSBy2TE38VZ9rHN/cza8jKhPNs7W1rN++Heq60zlZBK7jQODHk X-Received: by 10.152.245.168 with SMTP id xp8mr26662261lac.109.1439304292310; Tue, 11 Aug 2015 07:44:52 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id i7sm515951lag.9.2015.08.11.07.44.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 07:44:51 -0700 (PDT) Message-ID: <55CA0A5C.1020304@sics.se> Date: Tue, 11 Aug 2015 16:44:44 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net> <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> In-Reply-To: <55CA0837.5050008@nthpermutation.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050409030105060008060009" Archived-At: Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 14:44:56 -0000 This is a cryptographically signed message in MIME format. --------------ms050409030105060008060009 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-08-11 16:35, Michael StJohns wrote: > On 8/11/2015 10:28 AM, Hannes Tschofenig wrote: >> Thanks, Ekr. >> >> On 08/11/2015 03:33 PM, Eric Rescorla wrote: >>> This is already done. >> While I understand the reason for removing the functionality from the >> ServerHello I still think it is a needed functionality for many IoT >> deployments to obtain time information (without having to fall back to= >> NTP). >> > > Yup - but not all IOT devices will do DTLS or TLS. And time in DTLS or= > TLS isn't "secure". > > I think for this version, you should assume that DTLS and TLS will not > be a source of time and write accordingly. > > Mike If falling back to NTP means additional traffic (which I strongly=20 suspect) this is not a god thing in the IoT world. The attraction of=20 using DTLS/TLS is that you can piggyback the information in the=20 handshake (that you have to do anyways). So is there an alternative? Could we use RFC4680? /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms050409030105060008060009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4MTExNDQ0NDRaMCMGCSqGSIb3DQEJBDEW BBTOvFEwwys+0ocbd4wOpNRwid/L3jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAfHBzSBUWLuJB7WSFFdXihsNJP/h1GLBodkEYVKrt7VBCzsKVn4t6RWIefGF5oI1PeFd5 EigOyHBE9pJHTZSRkxG3sexipKIOeWbRkda8Bb+1p7QRNlxjTqkzD+ZiTbYK++m0TPzRiKOQ bAkoFw2MyCfNmToFJaUB/Tvrnna7CzDGou46F23IQE8GwIo7tH4b0Ai663CQJ3jjgvMLFZ6V tf7adEIBlOldJZc5Nanux0mDIe0oUx/ylCspp8W1oIwRxA1YHdlrP3m+V62e4E/9a4D9Yjt3 XFLD4ef5c1uGyH2KyIxcZDO1Tm6Vkvs8DUQ41p4p644TxJAqSe71iYpeoAAAAAAAAA== --------------ms050409030105060008060009-- From nobody Tue Aug 11 07:46:27 2015 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 055CD1A901F for ; Tue, 11 Aug 2015 07:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXjCLlEo_JG7 for ; Tue, 11 Aug 2015 07:46:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4771A8FD6 for ; Tue, 11 Aug 2015 07:46:24 -0700 (PDT) Received: from [192.168.131.134] ([80.92.114.74]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M6AbC-1YaEsu41Ws-00y63M; Tue, 11 Aug 2015 16:46:23 +0200 Message-ID: <55CA0AAB.8070808@gmx.net> Date: Tue, 11 Aug 2015 16:46:03 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Ludwig Seitz , dtls-iot@ietf.org References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net> <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> In-Reply-To: <55CA0A5C.1020304@sics.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KuD44OwpArnKJgBjpqTbXmCiRJNRl6Qci" X-Provags-ID: V03:K0:+bbZs6eHhgdT0fWu6rPtseZ1mBkbmjDpHCNlgEXhNCsPd+loJCw lefeQZVHRdQ4ZUkXBlRfIB+J1TiZVXA1LEZ/J2pkIclqaJh9UxWFNC35RaFFPIeIs+r8I/V Nlu4AbTtK3t2XmIeU2JNCiktDrVTAjKZKx6+COdxomVLb1FPeYjFmb+qvwClskje6ma91Yj DUFUcXkcmydfg7WXAMVZQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:noE6CwK8X9g=:3ofq0WqsXbNAjH9wiGiQi1 lFSLBzjvG/x2w2eqtHPTeAde5xnzKi+vKxFnjrbtgIvV0OT+VvOnMcTmAtzyFwXgpeJbbyXVA nZlD0Y3OcunlJCvT1s9ltk4oj+xodzu1x63QPsQrfDGACtWuUZh2EL2PxKv2o5ZWnrpkoTqDu MrNVGLMMo2Vi74HJ80Va04699MetR/Xzb9AriPwvYEygf3tQQ39NgG2cZhOpArU74xg120+ZC k/cXt4nA6fhILKnP7IA6GwZoFiwKWA6R+OEv61sKnDv2FHWInDhKreI/jxqWBdWsbyHj6zOF1 U+wLEzNKKjqet/nM4fSE75k9q66xMZ36FIalWDdQLYfahJlyXors7S4i+rrAO14tb8Z6F7dX0 MvlAMOp/3dTGS7i/j/hiCM8CfOPR5C0LMNbEJKFPo3A/6QazxnwJiKmVIHM6kZ8b4QpInu5/K l4lazkhkDyigGD6LI9Q6jH3LmQJfbdGULVeMkp3j20QIpoD/F9wKxQfUp7iwfbkKDZj486nTo BlW7Qzev0xA/B6WhohBCOk3xLlC5DFC+ezGjEnyREt3qp2GYXFqng1Q7hS8eEfYGJWy7V45Et ImU4s8EdeXTldWUGH3NyjrR54JRQjxwaCTmORmInRfcAa7g7UruvySFN0xBBo9at/ZIXhbbV5 ZOLT5gU7aIYWaAfXr564m3WmjKBeVUb5VHloxQfjFuqtYGZv3rzviLf8J59zc9RR0YBb4RnAC C9sLO/AHHpDTbR5t Archived-At: Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 14:46:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KuD44OwpArnKJgBjpqTbXmCiRJNRl6Qci Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A possible alternative is to do it like the Kerberos folks did it, namely by adding it to the key distribution mechanism (which would then be ACE). On 08/11/2015 04:44 PM, Ludwig Seitz wrote: > If falling back to NTP means additional traffic (which I strongly > suspect) this is not a god thing in the IoT world. The attraction of > using DTLS/TLS is that you can piggyback the information in the > handshake (that you have to do anyways). >=20 > So is there an alternative? Could we use RFC4680? --KuD44OwpArnKJgBjpqTbXmCiRJNRl6Qci Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVygqrAAoJEGhJURNOOiAtp2oIAIF38mhDZUTBdJqbbC2pBmSH E9p8zqZfwCEuKHqUe4H3/I8V2axiUK9FjKDs/ADu/G0cWJ1bAi700/lW26/OlGjR O1z/lGo/+jg7x7mmeR1OcGnFTS6C0jWjen/LXtDpGphPwmyFfYRMQESB9ZOAux7+ +oq75i0pXNOmZaq0qgIoaSIU9rsRGOcYDtTq6neRGOYk7Q9hai/Z6WCCy8YZTa1W 3vIUb9XMjGU+Hhalt05a7yJzCJa6CYRy4j0cATEDw9TdbzhF1kMA5x56m6b222DT 1Lz8ubNNWZQpOO1OH0gAI1AuRYHxIUyHY5T5UfSlHcNyPD/TSy3s6sSXVFHJKuo= =rH06 -----END PGP SIGNATURE----- --KuD44OwpArnKJgBjpqTbXmCiRJNRl6Qci-- From nobody Tue Aug 11 07:47:16 2015 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 499FE1A901F for ; Tue, 11 Aug 2015 07:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvccrz4m85Nv for ; Tue, 11 Aug 2015 07:47:12 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A021A8FD6 for ; Tue, 11 Aug 2015 07:47:12 -0700 (PDT) Received: by qgeg42 with SMTP id g42so104471100qge.1 for ; Tue, 11 Aug 2015 07:47:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=0ITikWbGDTS41ONoucY1yWX6rwbQbzAUH5Y+G7OP9Gs=; b=kBfcIUV9quDGS+IDlU/C4lqcvrNKu9ngjjjkVerGRPiDUNSeY+YsW9cyomxmlLInut SYdG8VgVDWuuTDBu50e1QmAN14xZZ1qhMBs953194mp9NOqEUg4dTuHiJTVnz5ChAFGo LlaHmQHQKozLaD4xPqAH7lQ87HYgq5cZB3tBraQG/fIGgzWJaP7yEOGcbEoHuoGgyMlK DPrlON4bH3k77nCE/3zB1U3BWpq524Ey356e9bqbABDC4LgzrWVD/Dj6llhwLwB6DKZJ kHzV5YsFqhxycYggujEm2ZbSI7/0o0rr+/njeO2kZg0o6T8WOkSwd+R/aizdCwYKUlkS TCxg== X-Gm-Message-State: ALoCoQkos2E1jkfyznL1MiTTTzywcp906shBUBpy/Y4dFVmLej7Kh1hudFAhfqXxZucIUhZTqlaw X-Received: by 10.140.194.198 with SMTP id p189mr51789234qha.42.1439304431014; Tue, 11 Aug 2015 07:47:11 -0700 (PDT) Received: from ?IPv6:2601:148:c000:1bb4:25a8:b49c:958b:8d09? ([2601:148:c000:1bb4:25a8:b49c:958b:8d09]) by smtp.gmail.com with ESMTPSA id 41sm747538qkp.9.2015.08.11.07.47.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 07:47:10 -0700 (PDT) To: Stephen Farrell , Hannes Tschofenig References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> <55C23E1B.5050300@cs.tcd.ie> <55C2687F.8050004@nthpermutation.com> <55C4BEE5.5080107@gmx.net> <55C7F80B.5020501@cs.tcd.ie> From: Michael StJohns Message-ID: <55CA0AF4.2070909@nthpermutation.com> Date: Tue, 11 Aug 2015 10:47:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55C7F80B.5020501@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] IP Addresses in Certificates 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, 11 Aug 2015 14:47:14 -0000 On 8/9/2015 9:02 PM, Stephen Farrell wrote: > Hiya, > > On 07/08/15 15:21, Hannes Tschofenig wrote: >> Hi Mike, Hi Stephen, >> >> I don't understand why we should make any recommendations for how to use >> IP addresses in certificates. > For which definition of "we"? My guess is that he was referring to DICE given the mailing list... > > I guess it is maybe wrong to consider the DICE WG doing this, but my > comment was really asking the question and not insisting on a given > answer. I didn't take your question as rhetorical either.... > >> IP addresses in certificates are not useful for end devices since their >> IP addresses is most likely not known during manufacturing nor does it >> add any security value. > Fair point. > > OTOH, there will be devices whose only visible identifier is an IP > address, right? If so, and if certificates/DTLS are to be of use with > such devices... then what? I do think some variety of "we" ought try > to address this problem. I don't think that's ever correct. The most visible identifier is generally going to be the L2 address which will generally be fixed from manufacturing. But that's immaterial as what's important is not the network visible identity, but the identity the device uses for its connection to the network and to IOT services. 802.1AR uses the Manufacturer device type OID/Serial number pair as the recommended identity for manufactured in certificates and that makes a lot of sense as both of those are human usable and tend to also be on the label on the device or device box. That makes it pretty easy to add them to access control lists in the IOT services server or to provide a secondary (and revokable) credential (after verifying the primary manufacturer/serial credential) that the device can use to connect to the network or local IOT servers. Going back to what I said before: > So I think your recommendation of "future work needed" is probably more > correct than "IP certificates needed". So I think we should close out this item for DICE. But might it be a better item for ACE? > >> Regarding IEEE 802.1AR I don't believe it recommends using IP addresses >> in certificates either. > Which is entirely fine. There are definitely better ways of naming > things than with addresses, esp relatively-scoped addresses. > > > S. > >> Ciao >> Hannes >> >> On 08/05/2015 09:48 PM, Michael StJohns wrote: >>> Hi Stephen et al. >>> >>> I'm coming in on this fairly late (2 weeks) so let me try and muddy the >>> waters: >>> >>> IEEE 802.1AR is a good source for ideas of how to deal with certificates >>> and small devices. In the case of Zigbee Smart Energy 2.0 for example, >>> we use their concepts of LDevID (Locally significant) and IDevID >>> (Initial) device identifiers. The latter is what gets built into the >>> device and SEP2.0 uses the SubjectAltName hardwareModuleName in RFC4108 >>> as the manufactured in name for the device. The attachment of a >>> certificate to MAC address or even IP address by the manufacturer has a >>> number of issues that are painful to address and that don't usually add >>> to the security of the system. (e.g. the handle of the name mostly >>> isn't important to the underlying protocols in IOT and the relationship >>> between an entity and its IP or MAC generally isn't a necessary >>> consideration for trust between entities given certificates - same >>> reason that client certificates for TLS rarely have IP addresses in >>> them, but do have human personal names or email addresses). >>> >>> Ideally you want a mapping between what's on the certificate inside the >>> device and what's on the label outside - so that humans can basically >>> type things in (or barcode them or....) during installation. I might >>> expect a local trust center to issue an LDevID based on the (manual?) >>> acceptance of IDevID, and the LDevID *could* contain an IP address as a >>> SubjectAltName, but I don't think we've gone that deep and most folk >>> balk at running a Mini-CA in their home. >>> >>> So I think your recommendation of "future work needed" is probably more >>> correct than "IP certificates needed". >>> >>> Later, Mike >>> >>> >>> >>> >>> >>> On 8/5/2015 12:47 PM, Stephen Farrell wrote: >>>> Hiya, >>>> >>>> On 05/08/15 15:54, Hannes Tschofenig wrote: >>>>> Hi Stephen, >>>>> reading through this issue again I believe you could help us further >>>>> explain >>>>> what we could recommend in the document. >>>> Assuming that it'd be a bunch of work to recommend how to best >>>> handle certificates for devices that will only ever have a bogon >>>> IP address, I guess the best for now is to just say that that work >>>> is not (yet) done and hence this document makes no recommendation. >>>> >>>> Seem ok? (And yes it could be that the current text on that >>>> is just fine, I didn't go look back right now) >>>> >>>> S. >>>> >>>>> Currently, we are saying that folks shouldn't use IP addresses in >>>>> certificates >>>>> and in the email below Thomas mentioned one reason for doing so. I >>>>> also pointed >>>>> to a separate draft we have been working on to explore the topic >>>>> further (see >>>>> ). >>>>> Ciao >>>>> Hannes >>>>> *Gesendet:* Dienstag, 21. Juli 2015 um 14:16 Uhr >>>>> *Von:* "FOSSATI, Thomas (Thomas)" >>>>> *An:* "Stephen Farrell" , "Hannes Tschofenig" >>>>> , "dtls-iot@ietf.org" >>>>> *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates >>>>> Hi Stephen, >>>>> >>>>> On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell" >>>>> >>>>> wrote: >>>>> >Hiya, >>>>> > >>>>> >On 15/07/15 12:07, Hannes Tschofenig wrote: >>>>> >> Stephen wrote: >>>>> >> >>>>> >> (5) 6.3: Forgetting CoAP for the moment, surely this profile >>>>> will be >>>>> >> used with devices that only have (possibly bogon) IP addresses >>>>> and that >>>>> >> want to have those in certs. I do get that how to handle that >>>>> well is >>>>> >> not very clear, esp. for certs for e.g. 192.168.0.1, but >>>>> shouldn't it >>>>> >> really be covered by this profile? >>>>> > >>>>> >I should also have mentioned link-local addresses too I guess. >>>>> >>>>> v6 link-local make sense as stable identifiers, but they'd be equivalent >>>>> to EUI-64 (which is what 6.3.2 requires for the use case where all the >>>>> secure communication happens on the same subnet), only a few bytes >>>>> larger >>>>> than their EUI counterpart. >>>>> >>>>> Other kinds of IP addresses aren't long-term/stable enough to be put >>>>> in a >>>>> certificate -- which is in line with the recommendation we give in CoAP >>>>> [https://tools.ietf.org/html/rfc7252#section-9.1.3.3]. >>>>> >>>>> Cheers, t >>>>> From nobody Tue Aug 11 07:58:25 2015 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 406D31A905D for ; Tue, 11 Aug 2015 07:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_MEN=2.3, RCVD_IN_DNSWL_LOW=-0.7] 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 jEGCRNrJKnMb for ; Tue, 11 Aug 2015 07:58:22 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C241A9029 for ; Tue, 11 Aug 2015 07:58:22 -0700 (PDT) Received: by qgeg42 with SMTP id g42so104741797qge.1 for ; Tue, 11 Aug 2015 07:58:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=vFdjE6IRbM13mnUaR9cWFVzJX06msMHXHmtSF9nC2Ro=; b=dBn2ojH7kxasI1yA9ZK0N/C/Q7ntKP598x3VMgWwnsloxOS6zl72LngAA0vaLhXWc/ K4NkEJl7Qmk0aTv20MlUibzPkM6bHCIiDeMQPKxgY2sILolJuhcK0Nk2kAN93Kh4EbQ8 y0smlsm0ma2FvEvMGQjUVezP2zg1igTWmk0uAoEzrCSTcEsZTStBFnUf1JIN7iXiyLWc 6DbBB8TbvXcngQIdwI+LiUCQzns+us+KBUqTQsuP2heAsIP/YYtnm/WyCjFkPde5EyHp iy8xuwcbaA62KEo9Fejk/EU657JxBlN1gDvSCjJ5KCGIE77OB7BBtnRE15DFk+FGDB+G Z74w== X-Gm-Message-State: ALoCoQn9onbv+/861xJ0dk/EPeMjp7B6kAYVWPDTMW97t7Gx+SoOddmfkSwqjrNC6QOmerELeHfX X-Received: by 10.140.239.84 with SMTP id k81mr51884950qhc.66.1439305101959; Tue, 11 Aug 2015 07:58:21 -0700 (PDT) Received: from ?IPv6:2601:148:c000:1bb4:25a8:b49c:958b:8d09? ([2601:148:c000:1bb4:25a8:b49c:958b:8d09]) by smtp.gmail.com with ESMTPSA id s91sm1295333qge.44.2015.08.11.07.58.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 07:58:21 -0700 (PDT) To: dtls-iot@ietf.org References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net> <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> From: Michael StJohns Message-ID: <55CA0D93.5020209@nthpermutation.com> Date: Tue, 11 Aug 2015 10:58:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55CA0AAB.8070808@gmx.net> Content-Type: multipart/alternative; boundary="------------000206070206020800090105" Archived-At: Subject: Re: [Dtls-iot] Secure Time (again) 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, 11 Aug 2015 14:58:24 -0000 This is a multi-part message in MIME format. --------------000206070206020800090105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 8/11/2015 10:46 AM, Hannes Tschofenig wrote: > A possible alternative is to do it like the Kerberos folks did it, > namely by adding it to the key distribution mechanism (which would then > be ACE). TANSTAFFL - there ain't no such thing as a free lunch. I don't believe that "secure" time is possible without persistent time and that's difficult to do for cheap battery operated IOT nodes (or so I've been told). The best you can do is generally "tell me N times" similar to NTP and hope you're part of the mesh hasn't been captured by bad data. There's also the tradeoff between precision and accuracy that needs to be considered. IOT nodes with cheap clock circuitry will drift. If you want millisecond precision and 1 part per billion accuracy you're going to be disappointed (note that I didn't do the math - I may have meant 1PPTrillion or 1PPMillion). Then there's the whole latency thing - you might get a signed time object from Kerberos, but that object may have been sent a week ago. If you have no persistent time and you're just coming up..... welcome to last week. I think any system on the mesh is going to require something like NTPs tell me N times to work. I don't think that NTP is a drop in fix though. Time is not a simple thing. Secure time is frankly arcane and not meant for mere mortals to delve into. :-) I'm wondering if it might not be a bad idea to invite Dave Mills to come to an IETF to do a presentation on secure mesh time and give us his thoughts. Mike > > > On 08/11/2015 04:44 PM, Ludwig Seitz wrote: >> If falling back to NTP means additional traffic (which I strongly >> suspect) this is not a god thing in the IoT world. The attraction of >> using DTLS/TLS is that you can piggyback the information in the >> handshake (that you have to do anyways). >> >> So is there an alternative? Could we use RFC4680? > > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot --------------000206070206020800090105 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 8/11/2015 10:46 AM, Hannes Tschofenig wrote:
A possible alternative is to do it like the Kerberos folks did it,
namely by adding it to the key distribution mechanism (which would then
be ACE).

TANSTAFFL - there ain't no such thing as a free lunch.

I don't believe that "secure" time is possible without persistent time and that's difficult to do for cheap battery operated IOT nodes (or so I've been told).  The best you can do is generally "tell me N times" similar to NTP and hope you're part of the mesh hasn't been captured by bad data.

There's also the tradeoff between precision and accuracy that needs to be considered.  IOT nodes with cheap clock circuitry will drift.  If you want millisecond precision and 1 part per billion accuracy you're going to be disappointed (note that I didn't do the math - I may have meant 1PPTrillion or 1PPMillion). 

Then there's the whole latency thing - you might get a signed time object from Kerberos, but that object may have been sent a week ago.  If you have no persistent time and you're just coming up..... welcome to last week.

I think any system on the mesh is going to require something like NTPs tell me N times to work.  I don't think that NTP is a drop in fix though.

Time is not a simple thing.  Secure time is frankly arcane and not meant for mere mortals to delve into.  :-)

I'm wondering if it might not be a bad idea to invite Dave Mills to come to an IETF to do a presentation on secure mesh time and give us his thoughts.

Mike




On 08/11/2015 04:44 PM, Ludwig Seitz wrote:

If falling back to NTP means additional traffic (which I strongly
suspect) this is not a god thing in the IoT world. The attraction of
using DTLS/TLS is that you can piggyback the information in the
handshake (that you have to do anyways).

So is there an alternative? Could we use RFC4680?


      

      

      

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


    

    

  


--------------000206070206020800090105--


From nobody Tue Aug 11 08:31:15 2015
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 752651A1A80 for ; Tue, 11 Aug 2015 08:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOve2Ng7s81w for ; Tue, 11 Aug 2015 08:31:12 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09D61A1A1D for ; Tue, 11 Aug 2015 08:31:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09F32BE9A; Tue, 11 Aug 2015 16:31:09 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amREPCg5ThJs; Tue, 11 Aug 2015 16:31:08 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BAABEBE3E; Tue, 11 Aug 2015 16:31:08 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439307068; bh=z5HFo+1ahvtdIRzaCruVwKMeAYIYPQMdI0J6pGPNnQg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Y4ZIx7S8KegW/Sw6Un/kGmo3zHFDvvLAVWmjGAaPBzB6gb7V6+bqRsjtu6KqzcmFU 7woMK33YEZeuQQq0AV5Flf6fTvB2YuO/fMpNpEnPBrJ6JL+zqQdF+vO4J2tW4JbGiW XJLrYOKVUXrPRusBSK0ic0dHpJEo6umv0vU/snzw=
Message-ID: <55CA153C.2080001@cs.tcd.ie>
Date: Tue, 11 Aug 2015 16:31:08 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Michael StJohns , dtls-iot@ietf.org
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com>
In-Reply-To: <55CA0D93.5020209@nthpermutation.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Dtls-iot] Secure Time (again)
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, 11 Aug 2015 15:31:14 -0000

On 11/08/15 15:58, Michael StJohns wrote:
> 
> I'm wondering if it might not be a bad idea to invite Dave Mills to come
> to an IETF to do a presentation on secure mesh time and give us his
> thoughts.

We could and that'd be a really useful great talk if it happened. But
we also have an active WG on this topic. [1] Maybe starting by asking
there would help?

S.

[1] https://tools.ietf.org/wg/tictoc/


From nobody Tue Aug 11 09:15:52 2015
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 E24601AC439 for ; Tue, 11 Aug 2015 09:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPDbZiTefgHx for ; Tue, 11 Aug 2015 09:15:49 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A291AC431 for ; Tue, 11 Aug 2015 09:15:48 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4830DE50F; Mon, 10 Aug 2015 11:47:50 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 510DA63B10; Mon, 10 Aug 2015 11:29:59 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3571563AE8; Mon, 10 Aug 2015 11:29:59 -0400 (EDT)
From: Michael Richardson 
To: Stephen Farrell 
In-Reply-To: <55C7F80B.5020501@cs.tcd.ie>
References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie>   <55C23E1B.5050300@cs.tcd.ie> <55C2687F.8050004@nthpermutation.com> <55C4BEE5.5080107@gmx.net> <55C7F80B.5020501@cs.tcd.ie>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: 
Cc: Hannes Tschofenig , dtls-iot@ietf.org, Michael StJohns 
Subject: Re: [Dtls-iot] IP Addresses in Certificates
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, 11 Aug 2015 16:15:51 -0000

--=-=-=
Content-Type: text/plain


Stephen Farrell  wrote:
    > OTOH, there will be devices whose only visible identifier is an IP
    > address, right?

I'm not sure that I agree.
I'm hard pressed to point a device that will have a stable IP address
that won't also have a stable name.  It might be interesting to figure out
how we can do things like put "printer.local" into a certificate...

If only we had SPKI, then you could say:
   (tcd's stephen.farrell's printer)


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEVAwUBVcjDdoCLcPvd0N1lAQILIAgAoMxp525OPvb0YsGomzfmb8+WnD60Bagx
83IwN5i5zDLkJLjIPbhZoUc1GN8XHj7DnoBDqdgvS+ig4tsUqf6JU02vmXfgq4kg
6BBgc5ivvp/516liHsxGz+gDxn/mnr/whOSC7mjy9IflYz+ZI6mJyvQlz2Ev9IIa
pF7zuRbhwVglUhGTNUP4fZEm8XgaThescT/GuG8wclU+Dhnlqzx2Kk4aTO7feK1u
q1GzpkvkYXrgRbgQvT2M5d13TpZFQhOvHSIJEWAzpr6X2tkES5B2xZUvHaHYR2dD
xhU2s0n0fM8ZKbLFtY66sdgA/QoyPgqpE+nPK4WbKyJ/jodoZ5c7gA==
=lNKO
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Aug 11 11:31:00 2015
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 90D941A885A for ; Tue, 11 Aug 2015 11:30:59 -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 341uiwBjFBeu for ; Tue, 11 Aug 2015 11:30:58 -0700 (PDT)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8EA1A876C for ; Tue, 11 Aug 2015 11:30:57 -0700 (PDT)
Received: by qgj62 with SMTP id 62so120664936qgj.2 for ; Tue, 11 Aug 2015 11:30:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=qjMVbxkQNrkSd9FHC4ABWEQQLpgRtdgqyPaehWpe3z0=; b=edEPh3x0tVIizaNORlhnxOD/KOhoNaUUqJo4VuUlAP/HQ3++ArbPOW0C+t0BgUalLc itO2zSpcm611ioIzM9VAswmF0OhUSft1R3bZNFo+9OtAJzQEOISVMZasMEq2GStoMwMj wTuGjcEsHW0/MnoCPSpylFjxZSTqLcbNzf0r1LJRE7Acc+ZkzXitdLyDke0Py50rsRE5 OUWFjWSojdhv0rX4hsl8MpRIWiRORhKFHDZcGPKivBD9yuIFG0g39czekDs+yl4xnMi/ VS9vpzLd4AvfI0fp3b+BEG9QtKgM/x+kPv5d0w3/x1p6xGz0nUwN5vXtKJ53+2BsUUEo AtQA==
X-Gm-Message-State: ALoCoQldYIjhRgqcgfovA64TRhbVnQkUQjbW/ooazQNhyxnLb4tSxmUMB4zJVt8kmcHZTMUaWYIN
X-Received: by 10.140.85.208 with SMTP id n74mr50453819qgd.67.1439317856951; Tue, 11 Aug 2015 11:30:56 -0700 (PDT)
Received: from ?IPv6:2601:148:c000:1bb4:5878:8b5b:6b96:a48a? ([2601:148:c000:1bb4:5878:8b5b:6b96:a48a]) by smtp.gmail.com with ESMTPSA id l108sm1680290qge.2.2015.08.11.11.30.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 11:30:56 -0700 (PDT)
To: Stephen Farrell , dtls-iot@ietf.org
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com> <55CA153C.2080001@cs.tcd.ie>
From: Michael StJohns 
Message-ID: <55CA3F65.20002@nthpermutation.com>
Date: Tue, 11 Aug 2015 14:31:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <55CA153C.2080001@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Dtls-iot] Secure Time (again)
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, 11 Aug 2015 18:30:59 -0000

On 8/11/2015 11:31 AM, Stephen Farrell wrote:
>
> On 11/08/15 15:58, Michael StJohns wrote:
>> I'm wondering if it might not be a bad idea to invite Dave Mills to come
>> to an IETF to do a presentation on secure mesh time and give us his
>> thoughts.
> We could and that'd be a really useful great talk if it happened. But
> we also have an active WG on this topic. [1] Maybe starting by asking
> there would help?
>
> S.
>
> [1] https://tools.ietf.org/wg/tictoc/

Hi Stephen -

 From the tictoc charter:
> The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is
>      concerned with highly accurate time and frequency distribution over
>      native IP and MPLS-enabled IP Packet Switched Networks (PSNs)

I knew about the group, but I didn't think it was a great fit for IOT 
stuff for a lot of reasons including their desire for "highly accurate 
time" against the IOT desire for lightweight.   As I read the charter, 
tictoc is NTP on steroids and what we want is NTP on depressants.  :-)  
They really aren't trying to solve a problem in a manner that would have 
applicability to IOT.

Mike



From nobody Tue Aug 11 12:00:51 2015
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 F1AA91AD248 for ; Tue, 11 Aug 2015 12:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI3KVrEQ0a5X for ; Tue, 11 Aug 2015 12:00:48 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0941B29DE for ; Tue, 11 Aug 2015 12:00:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD4F8BE7B; Tue, 11 Aug 2015 20:00:37 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBkqByz9-UgD; Tue, 11 Aug 2015 20:00:36 +0100 (IST)
Received: from [127.0.0.1] (unknown [86.46.29.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 83EEEBE75; Tue, 11 Aug 2015 20:00:36 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439319636; bh=xbkw9cxWqtgJ3IMy7eq7mexH+NmBQOzMacNxLl7Eypg=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=u4a/ji3FFM8DkkqKpAnypcpbAO4C9U437isGBt2MbnOelGkgN9wBJXrGma8wfMEat RbWeieGWoANAG6xVdunNiW2Cyyxbu2ic5LAiFkBD9SGkFOphkmWBIVyVOvQsTi8TnJ ktFPYKEEZQNK8+hMUKkOzCbTIxidT8EAtAkSiL1s=
X-Priority: 3
To: msj@nthpermutation.com
From: stephen.farrell@cs.tcd.ie
In-Reply-To: <55CA3F65.20002@nthpermutation.com>
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com> <55CA153C.2080001@cs.tcd.ie> <55CA3F65.20002@nthpermutation.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Date: Tue, 11 Aug 2015 19:00:34 +0000
Message-ID: 
MIME-Version: 1.0
Archived-At: 
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] Secure Time (again)
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, 11 Aug 2015 19:00:50 -0000

DQoNCk9uIFR1ZSBBdWcgMTEgMTk6MzE6MDEgMjAxNSBHTVQrMDEwMCwgTWljaGFlbCBTdEpvaG5z
IHdyb3RlOg0KPiBPbiA4LzExLzIwMTUgMTE6MzEgQU0sIFN0ZXBoZW4gRmFycmVsbCB3cm90ZToN
Cj4gPg0KPiA+IE9uIDExLzA4LzE1IDE1OjU4LCBNaWNoYWVsIFN0Sm9obnMgd3JvdGU6DQo+ID4+
IEknbSB3b25kZXJpbmcgaWYgaXQgbWlnaHQgbm90IGJlIGEgYmFkIGlkZWEgdG8gaW52aXRlIERh
dmUgTWlsbHMgdG8gY29tZQ0KPiA+PiB0byBhbiBJRVRGIHRvIGRvIGEgcHJlc2VudGF0aW9uIG9u
IHNlY3VyZSBtZXNoIHRpbWUgYW5kIGdpdmUgdXMgaGlzDQo+ID4+IHRob3VnaHRzLg0KPiA+IFdl
IGNvdWxkIGFuZCB0aGF0J2QgYmUgYSByZWFsbHkgdXNlZnVsIGdyZWF0IHRhbGsgaWYgaXQgaGFw
cGVuZWQuIEJ1dA0KPiA+IHdlIGFsc28gaGF2ZSBhbiBhY3RpdmUgV0cgb24gdGhpcyB0b3BpYy4g
WzFdIE1heWJlIHN0YXJ0aW5nIGJ5IGFza2luZw0KPiA+IHRoZXJlIHdvdWxkIGhlbHA/DQo+ID4N
Cj4gPiBTLg0KPiA+DQo+ID4gWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvdGljdG9jLw0K
PiANCj4gSGkgU3RlcGhlbiAtDQo+IA0KPiAgRnJvbSB0aGUgdGljdG9jIGNoYXJ0ZXI6DQo+ID4g
VGhlIFRpbWluZyBvdmVyIElQIENvbm5lY3Rpb25zIGFuZCBUcmFuc2ZlciBPZiBDbG9jayAoVElD
VE9DKSBXRyBpcw0KPiA+ICAgICAgY29uY2VybmVkIHdpdGggaGlnaGx5IGFjY3VyYXRlIHRpbWUg
YW5kIGZyZXF1ZW5jeSBkaXN0cmlidXRpb24gb3Zlcg0KPiA+ICAgICAgbmF0aXZlIElQIGFuZCBN
UExTLWVuYWJsZWQgSVAgUGFja2V0IFN3aXRjaGVkIE5ldHdvcmtzIChQU05zKQ0KPiANCj4gSSBr
bmV3IGFib3V0IHRoZSBncm91cCwgYnV0IEkgZGlkbid0IHRoaW5rIGl0IHdhcyBhIGdyZWF0IGZp
dCBmb3IgSU9UIA0KPiBzdHVmZiBmb3IgYSBsb3Qgb2YgcmVhc29ucyBpbmNsdWRpbmcgdGhlaXIg
ZGVzaXJlIGZvciAiaGlnaGx5IGFjY3VyYXRlIA0KPiB0aW1lIiBhZ2FpbnN0IHRoZSBJT1QgZGVz
aXJlIGZvciBsaWdodHdlaWdodC4gICBBcyBJIHJlYWQgdGhlIGNoYXJ0ZXIsIA0KPiB0aWN0b2Mg
aXMgTlRQIG9uIHN0ZXJvaWRzIGFuZCB3aGF0IHdlIHdhbnQgaXMgTlRQIG9uIGRlcHJlc3NhbnRz
LiAgOi0pICANCj4gVGhleSByZWFsbHkgYXJlbid0IHRyeWluZyB0byBzb2x2ZSBhIHByb2JsZW0g
aW4gYSBtYW5uZXIgdGhhdCB3b3VsZCBoYXZlIA0KPiBhcHBsaWNhYmlsaXR5IHRvIElPVC4NCg0K
U3VyZS4gQWxsIEkgbWVhbnQgYnkgJ2Fza2luZycgd2FzLCB3ZWxsLCBhc2tpbmc6LSkgSSBmdWxs
eSBhZ3JlZSB0aGF0IHdlcmUgd29yayBpbiB0aGUgSUVURiBvbiB0aGlzIHRvcGljIG5lZWRlZCB3
ZSdkIGhhdmUgdG8gZmlndXJlIG91dCBob3cvd2hlcmUgdG8gYmVzdCBkbyB0aGF0IGJ1dCB0aGUg
Zm9sa3Mgb24gdGhhdCBsaXN0IHdvdWxkIEkgZ3Vlc3MgYmUgYmV0dGVyIGluZm9ybWVkICh0aGFu
IG1lIGFueXdheTotKQ0KDQpTLg0KIA0KDQo+IA0KPiBNaWtlDQo+IA0KPiANCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZHRscy1pb3QgbWFpbGlu
ZyBsaXN0DQo+IGR0bHMtaW90QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZHRscy1pb3QNCj4=


From nobody Tue Aug 11 12:21:38 2015
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 88AFC1AD2C0 for ; Tue, 11 Aug 2015 12:21:36 -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 V77P0RQnZ-B7 for ; Tue, 11 Aug 2015 12:21:35 -0700 (PDT)
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40401AD2B2 for ; Tue, 11 Aug 2015 12:21:34 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so72709575qkd.3 for ; Tue, 11 Aug 2015 12:21:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=eB+POZ+H/d0PiJVUq3nd6piTa1jZY4Xvj2Sb85R+JuU=; b=herKMoa+vMn3BNEqdXD5968e7ibV3C0dMMrF8phiriW4ne9RSdjLpg+a+/VNKhP/X8 hw6cizeDSoQzliFlSFJH2YNTjqU6jrwSHPbnlPF5jXjkssoMm1UAm5uP6Oe3ArNPX1Tf gxEeW9CYNuz7fvRFFurUir5Hjf3h+JXeKnUBKVplrDnrRtNjOyxg8LM9P/HBupZcXdOz bHVPwlcZQ0bjsgY720I+xsm8r2nSrrLqPuXQCrhsakxkDjhAmweP6Mwz0F0AF7wUHSaf p5UWT56Ch9UB3XzKQDMKOVPHyiMl0zkzslFvIvdq4IK32PZAQRRbGXeKm+bG2yiq0Z16 9CDw==
X-Gm-Message-State: ALoCoQl1JhXWm+A2+snq+vYhaEPhFc9Kz+6cmLYlRh5PENGPVBIFu9xJF4WhaQVLEduYWmLY+4mc
X-Received: by 10.55.53.4 with SMTP id c4mr40045343qka.1.1439320894328; Tue, 11 Aug 2015 12:21:34 -0700 (PDT)
Received: from [192.168.1.102] (c-69-255-115-150.hsd1.md.comcast.net. [69.255.115.150]) by smtp.gmail.com with ESMTPSA id 15sm1755867qku.29.2015.08.11.12.21.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 12:21:33 -0700 (PDT)
To: stephen.farrell@cs.tcd.ie
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com> <55CA153C.2080001@cs.tcd.ie> <55CA3F65.20002@nthpermutation.com> 
From: Michael StJohns 
Message-ID: <55CA4B2E.7080603@nthpermutation.com>
Date: Tue, 11 Aug 2015 15:21:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] Secure Time (again)
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, 11 Aug 2015 19:21:36 -0000

On 8/11/2015 3:00 PM, stephen.farrell@cs.tcd.ie wrote:
>
> On Tue Aug 11 19:31:01 2015 GMT+0100, Michael StJohns wrote:
>> On 8/11/2015 11:31 AM, Stephen Farrell wrote:
>>> On 11/08/15 15:58, Michael StJohns wrote:
>>>> I'm wondering if it might not be a bad idea to invite Dave Mills to come
>>>> to an IETF to do a presentation on secure mesh time and give us his
>>>> thoughts.
>>> We could and that'd be a really useful great talk if it happened. But
>>> we also have an active WG on this topic. [1] Maybe starting by asking
>>> there would help?
>>>
>>> S.
>>>
>>> [1] https://tools.ietf.org/wg/tictoc/
>> Hi Stephen -
>>
>>   From the tictoc charter:
>>> The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is
>>>       concerned with highly accurate time and frequency distribution over
>>>       native IP and MPLS-enabled IP Packet Switched Networks (PSNs)
>> I knew about the group, but I didn't think it was a great fit for IOT
>> stuff for a lot of reasons including their desire for "highly accurate
>> time" against the IOT desire for lightweight.   As I read the charter,
>> tictoc is NTP on steroids and what we want is NTP on depressants.  :-)
>> They really aren't trying to solve a problem in a manner that would have
>> applicability to IOT.
> Sure. All I meant by 'asking' was, well, asking:-) I fully agree that were work in the IETF on this topic needed we'd have to figure out how/where to best do that but the folks on that list would I guess be better informed (than me anyway:-)

Maybe  -but a quick look of WG documents suggests that the science (and 
a lot of the engineering) for this has already been done in the IEEE 
1588  (Precision Time Protocol) group and that what's happening in the 
IETF is only the plumbing to make it work over/with IP.

I guess what I'm saying is that I don't actually know what I'd ask them 
that would be in their wheelhouse and that I couldn't get a better 
answer from Google or Dave Mills or maybe one of his (ex?) grad students.

No worries - I may drop Karen O a note to chat about this.

Mike

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


From nobody Wed Aug 12 08:17:19 2015
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 0BC801A8A52 for ; Wed, 12 Aug 2015 08:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] 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 4ft6OaIyE8tW for ; Wed, 12 Aug 2015 08:17:18 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3701A8A50 for ; Wed, 12 Aug 2015 08:17:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 832D1E2039; Wed, 12 Aug 2015 11:17:16 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24031-04; Wed, 12 Aug 2015 11:17:14 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2AAB3E2034; Wed, 12 Aug 2015 11:17:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1439392634; bh=Lh9R+I9KYZ8z0QXyvqVas8A2lpxBjZy1dvtVlhEem6c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=BBH6hx1OpmdTcyMxjaL8mykiaqOiRKDt0LPnM+fVIh0IQygKMZR2rQyjtY5HF0UIS PghJGHRyfPOaNhBI5ZFcj+lGMbpWfGfl97wjJEgvZ1TftQf0LCbpnPZ8ecIFB9knzC W47c4eYBB2T7DtgWXUdOt42FYka7L+6KkkE/dj3c=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7CFHDL2018788; Wed, 12 Aug 2015 11:17:13 -0400
From: Derek Atkins 
To: Michael StJohns 
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com> <55CA153C.2080001@cs.tcd.ie> <55CA3F65.20002@nthpermutation.com>
Date: Wed, 12 Aug 2015 11:17:12 -0400
In-Reply-To: <55CA3F65.20002@nthpermutation.com> (Michael StJohns's message of "Tue, 11 Aug 2015 14:31:01 -0400")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: dtls-iot@ietf.org, Stephen Farrell 
Subject: Re: [Dtls-iot] Secure Time (again)
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: Wed, 12 Aug 2015 15:17:19 -0000

Michael StJohns  writes:

> On 8/11/2015 11:31 AM, Stephen Farrell wrote:
>>
>> On 11/08/15 15:58, Michael StJohns wrote:
>>> I'm wondering if it might not be a bad idea to invite Dave Mills to come
>>> to an IETF to do a presentation on secure mesh time and give us his
>>> thoughts.
>> We could and that'd be a really useful great talk if it happened. But
>> we also have an active WG on this topic. [1] Maybe starting by asking
>> there would help?
>>
>> S.
>>
>> [1] https://tools.ietf.org/wg/tictoc/
>
> Hi Stephen -
>
> From the tictoc charter:
>> The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is
>>      concerned with highly accurate time and frequency distribution over
>>      native IP and MPLS-enabled IP Packet Switched Networks (PSNs)
>
> I knew about the group, but I didn't think it was a great fit for IOT
> stuff for a lot of reasons including their desire for "highly accurate
> time" against the IOT desire for lightweight.   As I read the charter,
> tictoc is NTP on steroids and what we want is NTP on depressants.  :-)
> They really aren't trying to solve a problem in a manner that would
> have applicability to IOT.

I actually attended a tictoc meeting a couple IETFs ago and presented
the IoT time sync problem to them.  They were unaware of the issue and
considered it an interesting problem to try to solve.

We should continue to engage them!

> Mike

-derek
-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant


From nobody Wed Aug 12 08:55:05 2015
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 14B521A1A32 for ; Wed, 12 Aug 2015 08:55:03 -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 Yr7P4_zQ2H0v for ; Wed, 12 Aug 2015 08:55:01 -0700 (PDT)
Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBEB1A8788 for ; Wed, 12 Aug 2015 08:55:01 -0700 (PDT)
Received: by qkbm65 with SMTP id m65so6558400qkb.2 for ; Wed, 12 Aug 2015 08:55:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=32dWI59SKKnif/Wcopv68TRVRmJn52xabmLQ5WI7qqk=; b=CFy+kIHjQyEqosmXNVytn+QJQqKOnAzVtky1PzjEcD3L/Ss+Ualy7wQlNt6hX4niL9 fqnbgPKmFN28W79A8uTAaRzaE6cWInWxwuQeOrRMGEi9sI1PYGAq1hFDI6lfpedvSBYE 8z3/A+HAxi5JuA3r643a/Xj4RSJHuwcDOeRB9yj2ZEtmQJCNcySJihGj38KtWzkl2yG2 SMq+31S2FeYMXclXo1GbsQVgo2lJV8J2FBe40VZ9wcY7tD4qS8RFO7hEa6jtqSdaILtT tajKwBkPrq43gy7BsBCm1yOwixi736moP2GU8tl4dKeYCLBa2jwHDHq9ImIuoHUMwUao uAtA==
X-Gm-Message-State: ALoCoQmjaLDoLLyEA9BcSliXOdwftBeB381a5ZL+PkkMerwTCLnm6LBVfyNIypLZGlocgNY88BVB
X-Received: by 10.55.23.99 with SMTP id i96mr60765535qkh.33.1439394900927; Wed, 12 Aug 2015 08:55:00 -0700 (PDT)
Received: from ?IPv6:2601:148:c000:1bb4:5878:8b5b:6b96:a48a? ([2601:148:c000:1bb4:5878:8b5b:6b96:a48a]) by smtp.gmail.com with ESMTPSA id 42sm3378724qkz.38.2015.08.12.08.54.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2015 08:55:00 -0700 (PDT)
To: Derek Atkins 
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com> <55CA153C.2080001@cs.tcd.ie> <55CA3F65.20002@nthpermutation.com> 
From: Michael StJohns 
Message-ID: <55CB6C5B.7090107@nthpermutation.com>
Date: Wed, 12 Aug 2015 11:55:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: dtls-iot@ietf.org, Stephen Farrell 
Subject: Re: [Dtls-iot] Secure Time (again)
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: Wed, 12 Aug 2015 15:55:03 -0000

On 8/12/2015 11:17 AM, Derek Atkins wrote:
>> They really aren't trying to solve a problem in a manner that would
>> >have applicability to IOT.
> I actually attended a tictoc meeting a couple IETFs ago and presented
> the IoT time sync problem to them.  They were unaware of the issue and
> considered it an interesting problem to try to solve.
>
> We should continue to engage them!
>

Charter creep is usually a bad thing.    I'm not saying not to do it, 
but it might actually be better to go to NTP (which Karen also chairs) 
and which is probably a better stepping off point than the IEEE PTP that 
Tictoc is working on.  It's probably that NTPv4 could incorporate IoT 
functionality better than Tictoc.

And for nothing else than a cool acronym, standing up an IOT integration 
working group  (e.g. to have a place to talk about all the pieces and 
how they can come together) might be even a better choice -> Interim 
Designs for the Internet of Things -> idiot.

Later, Mike



From nobody Thu Aug 13 06:36:29 2015
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 995761A878B for ; Thu, 13 Aug 2015 06:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 0pbJZ9s2-2Hg for ; Thu, 13 Aug 2015 06:36:26 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691441A875C for ; Thu, 13 Aug 2015 06:36:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 00970E2036; Thu, 13 Aug 2015 09:36:24 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31827-10; Thu, 13 Aug 2015 09:36:23 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4A18CE2034; Thu, 13 Aug 2015 09:36:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1439472983; bh=X0StS7gFQyZytlfGxb5wMnNkJZSiK/WwUwGkL0yCEx0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=HyIeHFD4fqPgOGAhpfftAyqtwagUVqn8uMz/V4j+Ean9uD9NtEYjQ0MiRbRns4Yws FHyRxjd7V7eIQ5icf0HkWG1f3XDrVactf2wt8+F6s7TaBxXKLr92Cp9AkDZzms3+AX kYmJthTgLLeypr2Ag7+UHYOFLjdTjEVzooj4Ym4Y=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7DDaMmR001808; Thu, 13 Aug 2015 09:36:22 -0400
From: Derek Atkins 
To: Michael StJohns 
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com> <55CA153C.2080001@cs.tcd.ie> <55CA3F65.20002@nthpermutation.com>  <55CB6C5B.7090107@nthpermutation.com>
Date: Thu, 13 Aug 2015 09:36:22 -0400
In-Reply-To: <55CB6C5B.7090107@nthpermutation.com> (Michael StJohns's message of "Wed, 12 Aug 2015 11:55:07 -0400")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: 
Cc: Derek Atkins , dtls-iot@ietf.org, Stephen Farrell 
Subject: Re: [Dtls-iot] Secure Time (again)
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: Thu, 13 Aug 2015 13:36:27 -0000

Michael StJohns  writes:

> On 8/12/2015 11:17 AM, Derek Atkins wrote:
>>> They really aren't trying to solve a problem in a manner that would
>>> >have applicability to IOT.
>> I actually attended a tictoc meeting a couple IETFs ago and presented
>> the IoT time sync problem to them.  They were unaware of the issue and
>> considered it an interesting problem to try to solve.
>>
>> We should continue to engage them!
>>
>
> Charter creep is usually a bad thing.    I'm not saying not to do it,
> but it might actually be better to go to NTP (which Karen also chairs)
> and which is probably a better stepping off point than the IEEE PTP
> that Tictoc is working on.  It's probably that NTPv4 could incorporate
> IoT functionality better than Tictoc.
>
> And for nothing else than a cool acronym, standing up an IOT
> integration working group  (e.g. to have a place to talk about all the
> pieces and how they can come together) might be even a better choice
> -> Interim Designs for the Internet of Things -> idiot.

All I did was attend the meeting and state the "need secure time at boot
time" problem with many IoT devices.  I didn't ask for a charter change,
just for them to think about the problem.  I figured that the tictoc
group probably had the most "time protocol" experts in the IETF.

Unsurprisingly they were completely unaware of this issue and were quite
intrigued by the problem.  Whether or not they work on it, I can't say.
I didn't follow up.

> Later, Mike

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant


From nobody Thu Aug 13 08:57:49 2015
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 028481A88F7 for ; Thu, 13 Aug 2015 08:57:48 -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 z58Ui47Ye1hj for ; Thu, 13 Aug 2015 08:57:46 -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 2AF801A88E6 for ; Thu, 13 Aug 2015 08:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t7DFvf5e001013; Thu, 13 Aug 2015 17:57:41 +0200 (CEST)
Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3msXbn3LSNz4vBk; Thu, 13 Aug 2015 17:57:41 +0200 (CEST)
Message-ID: <55CCBE73.4050002@tzi.org>
Date: Thu, 13 Aug 2015 17:57:39 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.1 (Macintosh/20150514)
MIME-Version: 1.0
To: Michael StJohns 
References: <55C4D1CE.6010802@gmx.net> <55C79A90.5070900@nthpermutation.com> <55C9CFB4.5070702@gmx.net>  <55CA0692.9000509@gmx.net> <55CA0837.5050008@nthpermutation.com> <55CA0A5C.1020304@sics.se> <55CA0AAB.8070808@gmx.net> <55CA0D93.5020209@nthpermutation.com> <55CA153C.2080001@cs.tcd.ie> <55CA3F65.20002@nthpermutation.com>  <55CB6C5B.7090107@nthpermutation.com>
In-Reply-To: <55CB6C5B.7090107@nthpermutation.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Derek Atkins , dtls-iot@ietf.org, Stephen Farrell 
Subject: Re: [Dtls-iot] Secure Time (again)
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: Thu, 13 Aug 2015 15:57:48 -0000

Michael StJohns wrote:
> And for nothing else than a cool acronym, standing up an IOT integration
> working group  (e.g. to have a place to talk about all the pieces and
> how they can come together) might be even a better choice -> Interim
> Designs for the Internet of Things -> idiot.

That acronym is taken -- it stood for "Improving DTLS for the Internet
of Things" -- the WG that then surprisingly became DICE (i.e., the WG
behind this mailing list).

On a more serious note, if you want to have a discourse about IoT
protocol integration issues, T2TRG may be the right place to talk about
this (before we come up with some specific topics for standardization).

https://www.ietf.org/mailman/listinfo/t2trg

Grüße, Carsten


From nobody Mon Aug 17 03:20:40 2015
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 7CB2E1A9031 for ; Mon, 17 Aug 2015 03:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tXRWm6qkg7N for ; Mon, 17 Aug 2015 03:20:36 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85ABF1A9030 for ; Mon, 17 Aug 2015 03:20:36 -0700 (PDT)
Received: from [192.168.131.138] ([80.92.114.40]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LosFD-1Yq0y10OHT-00gqMO for ; Mon, 17 Aug 2015 12:20:34 +0200
Message-ID: <55D1B571.2040209@gmx.net>
Date: Mon, 17 Aug 2015 12:20:33 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Croke9bGMaDiP8vIFj82Kfpj9F6vh63Da"
X-Provags-ID: V03:K0:UGcv6YKLfUHrScpYlNbI8JGcNSRI7XhJhypxE31CrVszBKEOyAS 52ZWGKBT6ql9Iwla6E0j6xcaR2i9pllt9KI9cQznDvoFalt68AN51a53quB8ew6o/4vwhXJ dLJicQzOGDGmwlc567vUxAQcb6UKKOqUOTuPNFHYGO3ZxFAQjoM7+cWODasWMQIeQ7PFUU6 ZfhWA06kCyLrEhFVz/uCw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:YNYgGEGtyTk=:Sn91iTla3QlBLhOYcSGwth zVPuQBuAe3Lr9TohQvkzp1crvhWUMrxAWmNMQ2uIMoC93ud5ygluo88lScw3WzvyglGhm7iAv e2dItNE5Fs2VMNaZ0QXWv8URLbU/VgJgVW4Ie0Jm8ilKcaw3BwUxuhNDoKl3BOeip24JUyw07 icdVKi+yian9/t0p/UorJfUgsq7zJuwMuI4mobgbR2+nOiTtcTtetZOQKoOHZlpPhqm34DtCD GTZkbI5xQAAP79ichTHiPivbcDWL2hklx79GO0tAhjr9sbHpAtF+rcZexVtWUfQZ+rnrHqLA3 d7BSpY0aG5ns7GEqJdoXTYGqocekrL5XO2tjACUhTMx4OwSjj8p1brkMSCPYWHCDw3wURO1MB 2/IyAn2dR8eCx6XcRhNWHDfCBLuy2CrOFmd+AV13nzU45+QMQ117d4IWGmi41cf+GaRxf3R0R hdtzMsIMHcUTjqgmSI6SWUWsPx0nGnkerDyPQ/GpJlSzXvebpUqi46n5tglrdDrr6UlT+1yTA vEYev9G4OXKo4v8eG9ECBN1oEsd9GrW3q07IV6Vay58N5zl/1ILUXPJtzSXK6ik+boDIv77Rb MVWCHL0Gsm+S2CA4YZsOkeSuDPWA93WFTTV+JFzw4hkwyUBQDkrqc9/DG31cbTfJVg6vWZcL8 jVh3ChezfO2S+WHNp1tBOpul4r4VLi5eS65nZp0Fgt2ftMfKHc09WUYg6eZZ6WvtQLthm1iaj GIGFT6RZiWSjKNuX
Archived-At: 
Subject: [Dtls-iot] Secure Time Summary
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, 17 Aug 2015 10:20:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Croke9bGMaDiP8vIFj82Kfpj9F6vh63Da
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

this topic lead to a longer discussion; references are here:
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00628.html
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00629.html
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00657.html

The conclusion seems to be that we do not want to incorporate a secure
network time protocol functionality into the TLS protocol but rather
offer it on a higher layer.

Thanks for your feedback.


I therefore suggest to change the following paragraph

FROM:

---------

   The ClientHello and the ServerHello messages contains the 'Random'
   structure, which has two components: gmt_unix_time and a sequence of
   28 random bytes. gmt_unix_time holds the current time and date in
   standard UNIX 32-bit format (seconds since the midnight starting Jan
   1, 1970, GMT).  [I-D.mathewson-no-gmtunixtime] argues that the entire
   ClientHello.Random value (including gmt_unix_time) should be a
   sequence of random bits because of device fingerprinting privacy
   concerns.  Since many IoT devices do not have access to an accurate
   clock, it is RECOMMENDED to follow the guidance outlined in
   [I-D.mathewson-no-gmtunixtime] regarding the content of the
   ClientHello.Random field.  However, for the ServerHello.Random
   structure it is RECOMMENDED to maintain the existing structure with
   gmt_unix_time followed by a sequence of 28 random bytes since the
   client can use the received time information to securely obtain time
   information.  For constrained servers it cannot be assumed that they
   maintain accurate time information; these devices MUST include time
   information in the Server.Random structure when they actually obtain
   accurate time information that can be utilized by clients.  Clients
   MUST only use time information obtained from servers they trust and
   the use of this approach has to be agreed out-of-band.

---------

TO:

---------

   The ClientHello and the ServerHello messages contains the 'Random'
   structure, which has two components: gmt_unix_time and a sequence of
   28 random bytes. gmt_unix_time holds the current time and date in
   standard UNIX 32-bit format (seconds since the midnight starting Jan
   1, 1970, GMT). Since many IoT devices do not have access to an
   accurate  clock, it is RECOMMENDED to place a sequence of random
   bytes in the two components of the 'Random' structure when creating
   a ClientHello or ServerHello message and not to assume a structure
   when receiving these payloads.

   When TLS is used with certificate-based authentication the
   availability of time information is needed to check the validity of
   a certificate. Higher-layer protocols may provide secure time
   information. The gmt_unix_time component of the ServerHello is not
   used for this purpose.

---------

Ciao
Hannes

PS: This text is documented in issue#31 (and issue #32 was merged with
issue #31).



--Croke9bGMaDiP8vIFj82Kfpj9F6vh63Da
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJV0bVyAAoJEGhJURNOOiAtk0kIAI6ViA0iRnC52ae4xQrNRXqX
OL1dxjvC8sHVmIEbKDmo1iwM7rGMRFmoXVk0Zjh+JdYJIQ4KTa0sNDWrdAkdm6GL
kdWTGA6ic1pCvE6nbe/dQZhBN4SHkrKgcV1sQN5JpIfXFpRhIPFhz3lpHyH220U7
FN3uqKfSlyHi8Imx4zOMF+hn5s4WcxaBIr84G/sXz8Xa7FoaXqA1tAEugaJgE3mq
fGBH9ZEyfkeTCxSvIG4uKlcLy0vwdPvqsJQzF2/26quOXNr4ZY6N+PSIxivXBYS+
QzGv6hNxbSesXARcXbF6e1c6HwkKpG0ZP4dBNgv1B3s3o1PfxIvLWl0PDcntXGw=
=DphA
-----END PGP SIGNATURE-----

--Croke9bGMaDiP8vIFj82Kfpj9F6vh63Da--


From nobody Mon Aug 17 05:31:21 2015
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 81BA51B2D46 for ; Mon, 17 Aug 2015 05:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVFpF-zFGcb3 for ; Mon, 17 Aug 2015 05:31:18 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C26C1A065C for ; Mon, 17 Aug 2015 05:31:17 -0700 (PDT)
Received: from [192.168.131.138] ([80.92.114.40]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LqALY-1YnYxv45NA-00dk3o for ; Mon, 17 Aug 2015 14:31:16 +0200
Message-ID: <55D1D413.4050205@gmx.net>
Date: Mon, 17 Aug 2015 14:31:15 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1bAte4f5MRlsXXVC2i9NTRssNTpMoaeRc"
X-Provags-ID: V03:K0:vAfbeGPILzb+ZQHOoVbalvRLCdnOjuoztk4opUlewbeoq2Ge/O9 Viy0uGB5uaKSDASJaunCzemf7nbpaboo2F5709NpKTKXeNCDKGhpICI12vbVsEooVLUAjmf jPkSsNqwRbXfqX898zRBvv8cTV7hzXAXtPeRq+Izy3EXLffBHh3bSbS1AzI0WDBoYxUzdfK z4f73NF68FnRhfPayyUVA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:fzqJcttlnN4=:A2/Y3z66M7GE5Gn52V7qoi KY3cdVei6vpFtgCju3+pmKStwWmaO2wJ0WAfovQ82IZDS8voGoDk4EQkP6jj3q+AnHF/XECgv JvO5/Jl271lQ9yww6bumSmNJdDCORbAuTz38xzV2VJWo5K8kAS2b8/HPBqrLrnarLtrOMPlEK moCce9Q4WWWGLPl2ylVfeGws0KR1DK9c1Jp2mLV2rghclfRW/xerImv8j5/D/1xzMKmgk15tI ypZNKfhsyqKMvjMWMrEgwzyTD8oYvbmrdvEgp+necpb79M5QXgm+0kKj7EP+ATiyCWpj6eYzv VPxP04l1dfDJ96qKAX9BGgClRB+rX/wcs1jCEQoh3aJcOZNHAmvxhsE73LKcJShXGSMxEID0C mfUL2T0OOhdpaSBJ3/4iSoFn6yl8iwixqKNPltmbrUrdgbU27iNGqwVsJAAPmEufs7dVIkWd6 zWu53wIBdLoPSATxHCJQmM5cM/SE/M31RGlhs6NSJx518TkcbfhLhQw/lBQkodOOCEDu3fn7U ebrfoVugcHe1LdqicAiXmJsz9teH0ZE8xsNxvVyv6CcFih+c77CgKCgYezoN16kLVuZK4ysqn ijzbT2ogWm6eX5FDhqqiN6PAvSKbVBbIdmPYJpsy8+Z12mBMOXMTRLFX42d3qMtfjSDrsKDc8 7toYfcpgWe17hyaBmEXO+izx1HXCN6zphMhByC6Eeg83CaZYXYlhMOgvYn1LUdWueZaw/aSqH YMkbNRle+0u0f7X2
Archived-At: 
Subject: [Dtls-iot] Privacy Considerations
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, 17 Aug 2015 12:31:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1bAte4f5MRlsXXVC2i9NTRssNTpMoaeRc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

Stephen wrote:

(12) 24: You need to mention that simply emitting a
packet can be privacy sensitive and that (D)TLS doesn't
help if so. For example, if lights turn on when I enter
the room and those packets can be detected then seeing
any packet says someone has entered the room. Or if a
thing I carry about sends out nicely encrypted stuff
then seeing the destination IP for that might have the
privacy issue. Or if a sensor has a threshold and only
fires above/below that then seeing any packet means
we've crossed the threshold. Text that explains that and
that that's a system and/or application layer issue is
needed I think.


I added a paragraph to the privacy considerations section:

-------

   Note that the absence or presence of communication itself might
   reveal information to an adversary.  For example, a presence sensor
   may initiate messaging when a person enters a building.  While TLS/
   DTLS would offer confidentiality protection of the transmitted
   information it does not help to conceal all communication patterns.
   Furthermore, the IP header, which is not protected by TLS/DTLS,
   additionally reveals information about the other communication
   endpoint.  For applications where such privacy concerns exist
   additional safeguards are required, such as injecting dummy traffic
   and onion routing.  A detailed treatment of such solutions is outside
   the scope of this document and requires a system-level view.

-------


I hope this resolves issue#35:
http://trac.tools.ietf.org/wg/dice/trac/ticket/35

Ciao
Hannes



--1bAte4f5MRlsXXVC2i9NTRssNTpMoaeRc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJV0dQTAAoJEGhJURNOOiAtSzoH/R7AlRvP+/sTC/ViQm2I6D8N
QDNjiKMDfcOLgGybrU0CxnCND49UlG8EYpaHv+7OHepbLYwzekDpc2IezyBNcv6d
N6oAn6BH6CErAREvAWkdLC5QGlr+vGH29uAfADb8LlOi4+xf5q3+lFYoKJn1Nveq
AGDxJX8T91j6762MsjTszY7WfQE7dByaIxOuc0qPF2kbBkewVHMl0QleOe0xfzYK
CQMzuJibd312kU+lDcws/Yu6yg19qWBOIQZb4AIROXXF9FFVGvNYnJBcIsYfdvfa
EiIEv4izktZF3ZBOsQ9BfGpjJGoYe2Teomb+uHnc0WQOIOO9X0P51cL1n/z0jW8=
=/4pg
-----END PGP SIGNATURE-----

--1bAte4f5MRlsXXVC2i9NTRssNTpMoaeRc--


From nobody Mon Aug 17 06:59:17 2015
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 9B27A1A00DC for ; Mon, 17 Aug 2015 06:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxM2CLPl9GG8 for ; Mon, 17 Aug 2015 06:59:13 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C041A00A0 for ; Mon, 17 Aug 2015 06:59:12 -0700 (PDT)
Received: from [192.168.131.138] ([80.92.114.40]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxgHz-1YhBZ73Ma3-017Co1 for ; Mon, 17 Aug 2015 15:59:11 +0200
Message-ID: <55D1E8AD.6080603@gmx.net>
Date: Mon, 17 Aug 2015 15:59:09 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L1l2B2CoBq4qFb3kHIwKVsRAEsCcmLNM2"
X-Provags-ID: V03:K0:tyR/N4AHTTStz6RXY5kQgtt20roCsdEXTsw0U/01QCmtAx2HlSI Oay0Xg91M/P0XtPklKsMKn074D+SEETxVYEHzer8oR9P70pjK1iEsCLvO11GNh56gW5cKlA IaGMy3s4k/lDbaWlbJ03JZUYoFj4lt0muhh+JvbTOnMrI9USaqhUrzYrphLUtEyVURHtzXa JDyfcvXJGh9QteOo3HZEg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:/iqisVjuoo8=:fIdTsNrG8OnSqzyqS/k1hf K9CcEGTGaIw5EP6ycspNI9vSAgLS76KWZ2lDyXFhAYAy42fKmRp6cTkrdRSRUi+Dmyneth2pD calW3zuQGts1NTVYAvFqENfg9xfnWiUqeSkFUPB0GtsMIqEXvlsBp5XKjaKqSYg5wfsU7hP6x SE0FvakZupHzPhHUp7UmWYOe78OELUjttn97F/ZVmll4T6ZIWQ2R+QE9tUXazsMb7Jcok6YKn CBhcOC1INOeXq/R1Iwa2MqILz35WYWDjJZOCkh8gWNq70P+1wDCriftC5jn5GT01jzMijT+VS B0K8+C3nwC0kidGU9OJjPBqDub4hEax93w2DiXTp/IUWrSj6foYjvjOQfYS2Hho+phr5KlZpB 6unVEQ9rH3JWK5AYMyQ6wbiwNpoWjwuqtcVB2pcM8FQMYayDSKr7nLjxudCFvf/LOrCVn7f// XWofSNk+46zbGDEG9Ob2Qhcbeus5P6OV6sDcRFFxQbKKrHkjJiBLRcyK/VSFJsp6r832lwenw zf7caguFTq0iBuu7jZ7PGaI2uAMua4BpcwFjoLYY7clCwdjCZ+ScjogTfysxWb2h+s4BhNpQX qVlc2CVuhVFW3YeM3m7GdkjSiutOzzVous9xOKnjAKpvVIy+BmHq7D4GHNb2Ug2sjESBkbLE9 Jbu5h0KpcozO+U7mhZ1iWSYfDYeSKDytiXYN3sN1JYdjRnQLiwe3NljkwTSymmaGytz5rgshV gaw5fbaebU29dAPU
Archived-At: 
Subject: [Dtls-iot] IP Addresses in Certificates: Summary
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, 17 Aug 2015 13:59:14 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--L1l2B2CoBq4qFb3kHIwKVsRAEsCcmLNM2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The comment from Stephen about the lack of guidance for how to put IP
addresses in certificates raised a longer debate on the mailing list,
see http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00625.html

The conclusion of the debate is that IP addresses in certificates are
out-of-scope for this document.

Issue #28 http://trac.tools.ietf.org/wg/dice/trac/ticket/28 is closed.

Ciao
Hannes


--L1l2B2CoBq4qFb3kHIwKVsRAEsCcmLNM2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJV0eitAAoJEGhJURNOOiAtON8H/jthS0JrNbp8tqk1IaCeXoXU
pOFAf8m53tt4MRuFR0fWe/ZozfiqkV9v6D178XqlhFfur8ab/sDlYFBF5dHSyg6B
xCKBMXS/RH16CoZNEWTI7XuIuGVsnjM1crtuhE8W6Oide6cx65eU6h7HJf98g2X9
XmYy8wFb6Ul7zc8ApOK7oSaIMVNtQ+KvpyZ5ryoBk6HVLsTD0m+yhNWdp+oAv1H7
4EfmgrDiqIkdJomeKTvI0pxy6/GwqeMusNPBOhceLDXQn83JnDs95DM5tJdSzXX2
6A2c75ycsO2nm/tLqhv5mQzsxvijVAAremvqTovGVCuzB1zsYi88MRaTDdigEvY=
=OCjo
-----END PGP SIGNATURE-----

--L1l2B2CoBq4qFb3kHIwKVsRAEsCcmLNM2--


From nobody Mon Aug 17 07:03:49 2015
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 0D65B1A0252; Mon, 17 Aug 2015 07:03:46 -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 NENG6_iRx9Mv; Mon, 17 Aug 2015 07:03:44 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7F61A00A0; Mon, 17 Aug 2015 07:03:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150817140344.21353.83654.idtracker@ietfa.amsl.com>
Date: Mon, 17 Aug 2015 07:03:44 -0700
Archived-At: 
Cc: dtls-iot@ietf.org
Subject: [Dtls-iot] I-D Action: draft-ietf-dice-profile-14.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: Mon, 17 Aug 2015 14:03:46 -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           : TLS/DTLS Profiles for the Internet of Things
        Authors         : Hannes Tschofenig 
                          Thomas Fossati
	Filename        : draft-ietf-dice-profile-14.txt
	Pages           : 58
	Date            : 2015-08-17

Abstract:
   A common design pattern in Internet of Things (IoT) deployments is
   the use of a constrained device that collects data via sensor or
   controls actuators for use in home automation, industrial control
   systems, smart cities and other IoT deployments.

   This document defines a Transport Layer Security (TLS) and Datagram
   TLS (DTLS) 1.2 profile that offers communications security for this
   data exchange thereby preventing eavesdropping, tampering, and
   message forgery.  The lack of communication security is a common
   vulnerability in Internet of Things products that can easily be
   solved by using these well-researched and widely deployed Internet
   security protocols.


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:
https://tools.ietf.org/html/draft-ietf-dice-profile-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dice-profile-14


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/


From nobody Mon Aug 17 11:47:12 2015
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 C64121B2ED1 for ; Mon, 17 Aug 2015 11:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEoBQPwxNJMu for ; Mon, 17 Aug 2015 11:47:08 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DDA1A8992 for ; Mon, 17 Aug 2015 11:47:08 -0700 (PDT)
Received: from [192.168.131.138] ([80.92.114.40]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LyR1G-1YfkYm2HNm-015tqE for ; Mon, 17 Aug 2015 20:47:06 +0200
Message-ID: <55D22C29.3060006@gmx.net>
Date: Mon, 17 Aug 2015 20:47:05 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" 
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EG7VdcI6Qm03cHbQ3kb1lnb1hOvgUc3dh"
X-Provags-ID: V03:K0:+JwNV55rfePYBknukeXJkvfY9BYF8JCb0BM5tUzR1Wg4aaQ7sqb 6grsPsrQB5BnnEVTVMGatVMyLjoIm8WXFsspMDxuSm8yXBxM5Wipw4QhFImTGBxU+K2I3mn EkFnDxX0F+wNdI49FT5VZHQGKmr+86syMshhBkGShZ9xyPnLePGz/Dozz914Id4rUi19jVL wGUAWvUX2eBdPx4/TgBYA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:mfa/gZRgvHU=:98neSFjAqYgBemr3N3RC0Y /YQHa5FCX4je8WNjMnXyWYnPHnpcpP/ayeWBVpiB51DLzhzKPHIzAhBp6TrThs6G70SKpzRBU d5dTkEc0Gq1/TZFLAMghOb0+/f5Kf62/p9ODFVbbfKtA69KXwL4fC4++skvf/AM0nl/1jgh2S Gt0KKMtWZUso9ZV7meVn4buL+cg4QDSYveyG6lN48Z9Gobt/Gf9aX4P9CpOLoisaKg8cFlm9B 84UShrbS1aarJu2JvLYuY1f7iF3UU0RcKeYN1LPD0skSVFrN7NnOYgkVYYo0eJevoKwP117Lr GY1bjffiw/xdp5QERCk17Roeo/GgUytBJpbhcxJ+hW9JX31Yom8fmgkFPzb2Kjkf3QRj+0HsA wPoIrK52MCigKFHDtnb1aBHBd4H8IKOU+SNVn9bTdoiIo2ljleztj1RAOzeWnXLMFImH2cdlr qXJec/jwBSgxzsRp0wxrK6c/sPAXcPLc8bxR0h5zJIeufMj2b0l4K90aWxV+wS6ifdrmW0JWp H6YSoArHOBFHO0w9XI4aq0o3BzDJTbBHr6NOrnCCpqGfhVdVo1m43cxIRiV7QAocI6WgGRsF/ l//K7QvtNXDVhRfRz+eADZTZRK/JtvkquiuqeReQ39OLrO1M0qW0yjnHam72Fdsx5L0vs6FVc Dd4g5hosSN3PZZjm1KZfZtCmjZl1q8YibMsXxMCvYkwsL2bxY87QqE2mkEFljF+XY+1lXHRTS n+8fkA6yoD9TLw6P
Archived-At: 
Subject: [Dtls-iot] Version -14 Submitted
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, 17 Aug 2015 18:47:10 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EG7VdcI6Qm03cHbQ3kb1lnb1hOvgUc3dh
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

I had a chat with Stephen today and we went through all the issues as
recorded in the issue tracker.

Stephen had a few remarks but was in general happy with the feedback
from DICE and CFRG.

As a result, I have published version -14 with the proposed text (as
recorded in each individual issue at the WG tracker).

I closed the issues in the tracker but you can still see them here:
http://trac.tools.ietf.org/wg/dice/trac/report/6

Please have a look at the updated document. As you can see, there are
various changes in the document:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dice-profile-14.txt

Ciao
Hannes


--EG7VdcI6Qm03cHbQ3kb1lnb1hOvgUc3dh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJV0iwpAAoJEGhJURNOOiAtdDUH/iSBK4u3LnQgVfmk9dp+oYs3
tVTAab+xTHK+B0rBpbK/0qADeEc6wLVXW9Y8aeV2Z1y8gfnvUBTj0QAFMX4yqaEO
0qPb6bvRQUrHbZl2OSgxS3+O/+Fe8bNyavpGtEwvJhP2tmshE0yolRZ7DXw+m1Cr
pO74vVPhEPCkrAiXMWo4JPKoC8Vu/8QPshZTyUXooAkGS5FEpHRdi1A1q+SpEkSw
5ka5sQq9g+bF7cBDC90dgbog1vKVyP7pfcZ/S+pmwXRCIkhwEmvmKHohQtaIGgmt
0kGQPkwbjfMMD6fb3m9KWPBCxmJM3eZ+oqu259mcMMEInxWym7q7R6CpvxHm/Us=
=9rzQ
-----END PGP SIGNATURE-----

--EG7VdcI6Qm03cHbQ3kb1lnb1hOvgUc3dh--


From nobody Mon Aug 17 12:18:45 2015
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 9C4AD1A21A8 for ; Mon, 17 Aug 2015 12:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxIZ69hxssxs for ; Mon, 17 Aug 2015 12:18:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707C21B2F4B for ; Mon, 17 Aug 2015 12:18:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BFE3FBEBE; Mon, 17 Aug 2015 20:18:40 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7ewBlHmdGtn; Mon, 17 Aug 2015 20:18:39 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.42.22.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 614F1BEB5; Mon, 17 Aug 2015 20:18:39 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439839119; bh=MufmHusQayw/leI6t6N5CmxgcrX3NieorA+8r57OzeQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Kvmu8w0bAvA2v8J7fYrih6awaBU46o7UJUo7n96qof+i5XouZwyz3Q6HO3omPRwyg xBao19pfbwSpFaxUALiU8gW3/v4VpF7fyk1EL9Oysz1PpdNF0jobRp4aGIopTGs64o X6zKw0B/4ngeglQ2lZmlkdBDdmVtG3RjxksskoLE=
Message-ID: <55D2338F.5050306@cs.tcd.ie>
Date: Mon, 17 Aug 2015 20:18:39 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Hannes Tschofenig ,  "dtls-iot@ietf.org" 
References: <55D22C29.3060006@gmx.net>
In-Reply-To: <55D22C29.3060006@gmx.net>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b4NurcuB8cdieWxn6g9kvlmaBI7c8GNd1"
Archived-At: 
Subject: Re: [Dtls-iot] Version -14 Submitted
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, 17 Aug 2015 19:18:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--b4NurcuB8cdieWxn6g9kvlmaBI7c8GNd1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

I plan to check over the diff and assuming all's well (which I
do assume) start IETF LC unless the DICE chairs tell me to hold
off for some reason.

Thanks for the good discussion.

Cheers,
S.

On 17/08/15 19:47, Hannes Tschofenig wrote:
> Hi all,
>=20
> I had a chat with Stephen today and we went through all the issues as
> recorded in the issue tracker.
>=20
> Stephen had a few remarks but was in general happy with the feedback
> from DICE and CFRG.
>=20
> As a result, I have published version -14 with the proposed text (as
> recorded in each individual issue at the WG tracker).
>=20
> I closed the issues in the tracker but you can still see them here:
> http://trac.tools.ietf.org/wg/dice/trac/report/6
>=20
> Please have a look at the updated document. As you can see, there are
> various changes in the document:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dice-profile-14.txt
>=20
> Ciao
> Hannes
>=20
>=20
>=20
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot
>=20


--b4NurcuB8cdieWxn6g9kvlmaBI7c8GNd1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJV0jOPAAoJEC88hzaAX42iNw0IAJpVY//obl2E3qIgLd05V7Ik
/NdkugfFP/ICnOp0D7C3xZmyB4P6XJgwjlMnI8V8iWZMtywGVQU9Aa7yejxGr2J9
b9u5tQr9/bhKa+g7jBXKg8y+tEQdVze4Pa7rESb1ZiCmTXiEyh+34D66sKBfDakT
Nr8RL7z3dR6vYgZfQEQGCVGOWM/++4cnT68VvxoSRopuLlcaDPI1wwuafOZ0xFmP
uqmVm1p2gT+78u6UUcEqn0zNnBJD2Wv5pBX2Zral6nwvXfF5pQlINpSZdes3zHS1
VEn6ILhybdWwCTXkR81J0H+MOkf0eXfDOqPMXumAgRpX1PndgGg2DXuEUQfD+RU=
=leQA
-----END PGP SIGNATURE-----

--b4NurcuB8cdieWxn6g9kvlmaBI7c8GNd1--


From nobody Fri Aug 21 06:33:41 2015
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 736981A9023 for ; Fri, 21 Aug 2015 06:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsZcdNnXaSyK for ; Fri, 21 Aug 2015 06:33:38 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969341A901F for ; Fri, 21 Aug 2015 06:33:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6DB92BF53; Fri, 21 Aug 2015 14:33:37 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzd0qXC6tg3a; Fri, 21 Aug 2015 14:33:37 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 441B6BF51; Fri, 21 Aug 2015 14:33:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440164017; bh=PtLKPVpLpxgj35d/cdLwfwbE4DuyiG1Wlv3Tb9f0KDA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Nk8FKUh7ji/5yX4Qf+MdQIbcMWH5FqjIDYHXvTl08jeQzNOXdE4Zt778Majm1WF5n Ag9fYfLn9+pY6ZZqZWSYERwHqMfP2eQbW6UDDNm6l7ZGaXbJbEoSBeDT/So7F8i/6F OcOqWm6m5Ic+iQGzX4TkMRLGmp1M9rr/X6MzALe8=
Message-ID: <55D728AD.8050905@cs.tcd.ie>
Date: Fri, 21 Aug 2015 14:33:33 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Hannes Tschofenig ,  "dtls-iot@ietf.org" 
References: <55D22C29.3060006@gmx.net> <55D2338F.5050306@cs.tcd.ie>
In-Reply-To: <55D2338F.5050306@cs.tcd.ie>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pFsQlDaSNOaf08mQdPKrk9hVA5Scroao0"
Archived-At: 
Subject: Re: [Dtls-iot] Version -14 Submitted
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, 21 Aug 2015 13:33:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pFsQlDaSNOaf08mQdPKrk9hVA5Scroao0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 17/08/15 20:18, Stephen Farrell wrote:
>=20
> Hiya,
>=20
> I plan to check over the diff and assuming all's well (which I
> do assume) start IETF LC unless the DICE chairs tell me to hold
> off for some reason.

Checking done, a few nits below but I've asked for IETF last call.
Please fix these before IESG evaluation (I don't mind if you do
'em now or later on).

Cheers,
S.


- 4.1.1.2 s/Figure 4 and Figure 4/Figure 4 and Figure 5/ I guess

- 6.1 s/has to be know./has to be known./

- 6.1 maybe some quotes would help here, i.e.

OLD: We call the above-listed information device credentials
NEW: We call the above-listed information "device credentials,"

- 6.1 s/are often called 'root of trust'/are often called a
       'root of trust'/

- 6.1 s/these initial device credential/these initial device
        credentials/

- 6.1 nicely says "it MUST be ensured that a different key pair"
I think that'd be better if you said "different secret key
materials" as then that'd also cover the pre-shared key case.
(I don't think there are cases where we want to recommend
the same secrets be on many devices and those be used with
TLS.)

- 6.2 s/shorted authentication tag/shorter authentication tag/

- 14: one of the changes doesn't read correctly, I think you're
saying the right thing but the surrounding text results in
oddness, maybe

OLD:

   Since many IoT devices do not have access to an
   accurate clock, it is RECOMMENDED to place a sequence of random bytes
   in the two components of the 'Random' structure when creating a
   ClientHello or ServerHello message and not to assume a structure when
   receiving these payloads.

NEW:

   However this structure is being deprecated for privacy reasons so
   it is RECOMMENDED to place a sequence of random bytes
   in the two components of the 'Random' structure when creating a
   ClientHello or ServerHello message and not to assume a structure when
   receiving these payloads.

But I'm not sure if my NEW suggestion there is quite right either.

- ID nits whines [1] about a few things, please check those out.

[1]
https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/d=
raft-ietf-dice-profile-14.txt


>=20
> Thanks for the good discussion.
>=20
> Cheers,
> S.
>=20
> On 17/08/15 19:47, Hannes Tschofenig wrote:
>> Hi all,
>>
>> I had a chat with Stephen today and we went through all the issues as
>> recorded in the issue tracker.
>>
>> Stephen had a few remarks but was in general happy with the feedback
>> from DICE and CFRG.
>>
>> As a result, I have published version -14 with the proposed text (as
>> recorded in each individual issue at the WG tracker).
>>
>> I closed the issues in the tracker but you can still see them here:
>> http://trac.tools.ietf.org/wg/dice/trac/report/6
>>
>> Please have a look at the updated document. As you can see, there are
>> various changes in the document:
>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dice-profile-14.txt
>>
>> Ciao
>> Hannes
>>
>>
>>
>> _______________________________________________
>> dtls-iot mailing list
>> dtls-iot@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>
>=20
>=20
>=20
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot
>=20


--pFsQlDaSNOaf08mQdPKrk9hVA5Scroao0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJV1yixAAoJEC88hzaAX42i9VsH/i3KK12JZa3SKg005WvVPd45
y3m1mVrLZihMe0OT5+ZjnmIb4Xkcd0MmifowXl8rM9rqj+trDAFdeXe23SD7DxZ4
U25nKU9E3MwSyVwRaE9gABTAlkpWyKo/35ms6S4THdrkOYo1v7JhgVXgQia8PPsf
/9WysTkr+xDQ6fdozyNzHBEQebYcq3wPPHpxCUYmalBbLuxf6QYD2a0gMGUWme2z
+txZPI6bk5jBRj+enhVwDEDHASa2i+deM9ass/aD33noQ7/NzCxF3T+az1LFchqg
zUsrQN8y5yJUQbScxGYhcAQKQRReKWRc0dtIskMryVSCqFb0yT/O9lT9iZNh+pQ=
=ApFd
-----END PGP SIGNATURE-----

--pFsQlDaSNOaf08mQdPKrk9hVA5Scroao0--


From nobody Fri Aug 21 06:52:40 2015
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 079221A9080; Fri, 21 Aug 2015 06:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 sNn0uXal2mMH; Fri, 21 Aug 2015 06:52:35 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFFD1A8F37; Fri, 21 Aug 2015 06:52:35 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20150821135235.25559.80688.idtracker@ietfa.amsl.com>
Date: Fri, 21 Aug 2015 06:52:35 -0700
Archived-At: 
Cc: dtls-iot@ietf.org
Subject: [Dtls-iot] Last Call:  (TLS/DTLS Profiles for the Internet of Things) to Proposed Standard
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: DTLS for IoT discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Aug 2015 13:52:38 -0000

The IESG has received a request from the DTLS In Constrained Environments
WG (dice) to consider the following document:
- 'TLS/DTLS Profiles for the Internet of Things'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   A common design pattern in Internet of Things (IoT) deployments is
   the use of a constrained device that collects data via sensor or
   controls actuators for use in home automation, industrial control
   systems, smart cities and other IoT deployments.

   This document defines a Transport Layer Security (TLS) and Datagram
   TLS (DTLS) 1.2 profile that offers communications security for this
   data exchange thereby preventing eavesdropping, tampering, and
   message forgery.  The lack of communication security is a common
   vulnerability in Internet of Things products that can easily be
   solved by using these well-researched and widely deployed Internet
   security protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dice-profile/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ballot/


No IPR declarations have been submitted directly on this I-D.