From nobody Mon Jul 6 09:17:13 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 4AB2B1B2F87 for ; Mon, 6 Jul 2015 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 oYhRRhp6Pv6f for ; Mon, 6 Jul 2015 09:17:07 -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 A45141B2F6F for ; Mon, 6 Jul 2015 09:17:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 17BD8BDCF for ; Mon, 6 Jul 2015 17:17:01 +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 Lth_t6zqPaO4 for ; Mon, 6 Jul 2015 17:17:00 +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 18F09BE3E for ; Mon, 6 Jul 2015 17:16:57 +0100 (IST) Message-ID: <559AA9F8.6080005@cs.tcd.ie> Date: Mon, 06 Jul 2015 17:16:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dtls-iot] AD review of draft-ietf-dice-profile-13 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, 06 Jul 2015 16:17:12 -0000 Hiya, I've done my AD review of draft-ietf-dice-profile-13. It's a fine piece of work that's nearly but not quite ready. I have quite a few (13!) comments that I'd like to chat about before starting IETF LC and at least the last of those definitely needs a revised I-D. So I'll be marking this as needing that shortly. If it helps to get out an I-D before the Prague meeting starts just let me know and I can ok that. Most but not all of the things I'd like to chat about before starting IETF LC are easy, but need checking I think. And since you chose to make this a 55 page document, I've of course also got a bunch of nitty nits:-) Those can be handled before or after IETF LC from my POV, whatever's easier for the WG/authors. Anyway, I don't think it ought take us too long to resolve these issues and move this on to IETF LC and I bet people will think this is a really fine RFC when it does pop out from the RFC editor. Cheers, S. Things I'd like to chat about before I start IETF LC: ----------------------------------------------------- (1) 6.1: Is TLS_PSK_WITH_AES_128_CCM_8 still ok for CoAP? We're discussing taking all the _8 ones out for SRTP, i.e., from [draft-ietf-avtcore-srtp-aes-gcm] because of the 8 octet tag being too short. I'd need to go check if the same issues apply here, but maybe they don't. What do we think? If this applies to any of the ciphersuites here, it presumably applies to all so I wanted to check just in case. (Kevin Igoe and Magnus Westerlund are involved in that SRTP discussion in case it helps.) (2) 6.2: Saying that the client key pair "may, for example, be configured during the manufacturing process of the device" is not ok really. There have been too many cases where the same key pair has been used in whole production runs or worse. You need to add a 2119 instruction here that doing the quoted thing "REQUIRES a different key pair for each device that SHOULD be generated and installed in as-secure a manner as possible." Or similar text. I don't care where that text is added (6.2 might not be right) so long as it's not hidden away on page 54:-) (3) 6.3: How can you have a MUST for s/w update when there is no well-defined interoperable way to do that. I think s/MUST/need to/ would be right here. (I'd love to see us define the IETF bits of a s/w update mechanism that could be referenced via such a MUST but we don't have that today so it's a bogus MUST as written.) (4) 6.3: The Ed25519 reference should be removed or the text modified. CFRG are not selecting Ed25519 it seems so that would be misleading as-written. (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? (6) 13: sorry I don't get why a 1 second initial timer is an issue because messages "need longer" (we're not in a DTN, right:-) I don't think you've justified the 10s initial value and that might be bad in fact e.g. for sleepy nodes one might want a much shorter initial timeout so the node can go back to snoozing. (It could be that this 10s value was justified on the list, but I'm not getting it from the text. Or is it appendix A you're thinking of? If so, that seems overly specialised for a generic 10s recommendation.) (7) 14: Doesn't [Heninger] really cause many devices to use one RSA prime factor? That's not the same as "same keys again and again" and in any case you're not recommending RSA keys on challenged nodes here. Shouldn't you do the analysis of the impact of a dodgy PRNG on populations of devices that follow these profiles and not something else? (8) 14: You are RECOMMENDING to follow mathewson-no-gmtunixtime which is fine. That however means that that's a normative reference on which you need to wait. I'm fine with that, but the WG may or may not be. (9) 14: And also - if you RECOMMEND to sometimes use ServerHello.Random for "secure time" then don't you have to say that that's only to be used after one has verified the server cert/knowledge-of-PSK or something? Otherwise any old fake server could send me a time value then bail on the handshake, and I might set my clock to that. (The bad effect there is not related to certificate revocation btw, but more e.g. DoS for sleepy nodes or application layer nastiness.) (10) 14: I want to check that the WG are really ok with the "MUST" for h/w "quality" RNGs. I really like the idea, but it's very odd for the IETF to have such a MUST touching on the style of implementation. (Say if my entire implementation of TLS is in some kind of VM? Then I couldn't meet this ever.) I think we have to s/MUST/weasel-words/ there tbh, sadly - it's just not our job to mandate implementation styles. The following para though does the job nicely, so maybe s/MUST/ought to/ is enough of a change. (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.) (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. (13) Appendix C has an editor note that says that it's not finished. That's gotta be wrong, no? Minor/nitty comments: --------------------- - Title: You are actually defining >1 profile but the title is in the singular. Worth fixing? - 55 pages! Sigh;-) - So it seems like everything up to section 6 is just introductory and not normative text (or at least pages 4-19 or so). IMO that is too much and if we were earlier in the process I'd argue it'd be better reduced a lot or put into another document. As-is, I think you need to add text in the intro that says "If you're familiar with (D)TLS, then skip ahead to section 6" and then at the start of section 6 you need to say that the normative text really starts here. 6.1 is the first place I saw any 2119 keywords - "required" (lowercase in the draft) and a SHOULD NOT. - section 2 (or somewhere): it might be worth saying that TLS1.3 is being developed but that it is not expected that this profile will "just work" for that due to the significant changes being done to TLS for 1.3. That'd imply there may be a need for another profile later for TLS1.3 but that's ok, I'm not asking we start that work now, just that we explicitly say that 1.3 is underway and we're not expecting this profile to work for that just as-is. You do sort of say that in section 8, but that's a bit obscure I think. - section 3: Is RC4 really the only stream cipher defined for TLS1.2? That surprised me but I've not checked. - 4.1.1.1 has quite a bit of text - I'd have said it wasn't all needed and just saying EAP-TLS is relevant and some RFC pointers would have been enough. - Figure 4 spans 3 pages. That's too much. Can't you split that into two figures each on one page? - 4.1.1.2, last para before Figure 4: Are you implying that DTLS-server-initiated resumption needs to be supported? I don't know if that's reasonable or not. Is it? This is triggered by the combination of "After some time" and "the already established" which could be read to imply DTLS session resumption initiated by the resource directory. Maybe this is addressed later in the document though? - 4.2, para just after figure 5: Is "have to be solved" correct? There are really no other ways? I think s/have to/can/ is probably better. - 4.2: Something seems broken here "as described in Section 2 of [RFC7452] these different communication patterns. " - Figure 6 spans >1 page too and needn't. - Section 5 duplicates RFC5246. I'd say delete the lot would be better. I'll live if you don't:-) - 6.1: "While the server is not required to initiate a cookie exchange with every handshake, the client is required to implement and to react on it when challenged." Is that a piece of normative specification or just a description of what's already documented elsewhere? I think you should be clear about that. (As this'd be the 1st bit of normative spec in the draft I think.) - 6.1: "into the firmware" I think you should warn against doing this, even in a passing reference like this. Firmware is usally published and putting sensitive values inside that is a really bad idea. - 6.1, near end of p20: "bit-by-bit comparison" please say to make that constant time, just in case it got into a tight enough loop to expose information about what ought be secret. (I assume guessing the PSK identities that a device has configured in might be sensitive if it can be done remotely. I forget how mismatches in those are handled.) - 6.3: "is omitted from the chain" - I think a recent DANE draft required that the root keys be included in the chain. Just notin the potential mismatch in case someone cares about these kinds of device and DANE. (I'd say "ask Viktor" is the way to check that out.) - 6.3.3, last para: that's not a good argument - trust anchors do not get revoked anywhere near as often as end entity (TLS client or server) certs - so for constrained devices, I'd expect a higher revocation rate in theory. (Though I agree, not in practice.) - table 1: this has too much stuff that is syntactically required and where there is no real choice. Shorten the table by getting rid of all those where you've nothing more to say. The table spans 3 pages too, so please break it into two. - table 1, serialNumber: for what length serial do you require support? There was a time when longer serials were an issue for some implementations and I could see that happening again here maybe. If that is an issue, then probably so would subject and issuer where you might also want to add a bit more text. - 6.3.6: typo: "during the DTLS exchange provides" - section 8: Simplification is good but I wondered if these restrictions were going to simplify very much. I'd not be surprised if implementations had to be able to handle lots of the errors you say aren't needed in any case. So maybe doing this as non-normative guidance would be better (and hence moving it before section 6). - section 9 typo: s/server constrained/server is constrained/ - 10: CRIME needs a reference. You could use the UTA draft. - 12: typo s/my expire/may expire/ - 12: I think you ought refer to heartbleed in some way - some implementers might think that was a protocol design flaw and not follow this section if you don't. - 23: If false start is RECOMMENDED then it needs to be a normative ref. Do you want to wait for that too? - 25: I really like para 2, thanks. I'm not sure that the OMA thing is the answer. (It might be, I don't know.) - Appendix A: I'm getting WAP-flashbacks :-( Are you really recommending that A.3 be implemented? I assume not, but it nearly says that so I thought I'd just check. From nobody Tue Jul 14 01:53:43 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 06CE51A90D4 for ; Tue, 14 Jul 2015 01:53:42 -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 LBFh-W7wOSmx for ; Tue, 14 Jul 2015 01:53:40 -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 014861A90C0 for ; Tue, 14 Jul 2015 01:53:39 -0700 (PDT) Received: from [192.168.131.131] ([195.149.223.246]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LfC00-1YdRUn333A-00ophO; Tue, 14 Jul 2015 10:53:37 +0200 Message-ID: <55A4CD93.80800@gmx.net> Date: Tue, 14 Jul 2015 10:51:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.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="ooORnte8jwx3gxAcbRxJP9gUMUTsW6Wv8" X-Provags-ID: V03:K0:B2a4PKzeQG5FsSFnmbHRveeHa5sC15SUhKOwBEgIHAlTJ2Qvoug F4qAARZiK4sU6VM55yFybwORTIWHqmMd3mzGvcnI5/C470GB8R+Ve4Vm9hXAMkehz/r3HIA HOHggbG8w7d8wh8+04wg+9rKBpxm3n8KSCgqsMaQZbMYc+MoOTHZcc+4JHjYmiT6JNNatKH sIWrA0zWv7jdl8Z/gtsXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:lWah39TUoo0=:+ncRdJVD+HSc+fI/SIR/4S wHN6+PsUTHliMqu+zx0qtLYnqjxoyarWTa9DUqK7w10pMI38rmF2iCEdr08I+mzGDkCerNStC FVB4DB1BpTC+0uwga3fenK0n3OEUW/fmyfmJL+cVTIQfHBzwH/8EL4Wc3Nq4IehljkKqU7/5t 6/j6iGHONPdkKVIcL9e8Y6yW/1c5+PxbN0gCkLUjH9GKjCYc1j7VVVmmgG6EHVOgbD6WQaLeq Ii5YiUnZRavsYfpgyWvtQAzggrATRDuPACYXPTh1Z04z+saaTAegHrAKFva+Ufyzbtpq2JC6Y WRFF9/kiYaBXxvLvqyKVc7n34wguOXlfgMoS8I46PlClKHH/o/Q6fuPZCGBqYDZUegOq9OQcv m2ozGG7hUDxZ+T0quS+XMTw5SGQBzFWHW0VGagCmeg8vBtPGDgwd2/USdtaU5zl0n3SbBRbNP Zyu2ey515odCZ6bPzQDlRsvTCpABIikagUaJXSxNfVUQZGM25ntdY9puYDsqAoKI9ATXFxeqN tZ6juoFBx9+grOdBUxktKjlb3I+T65LrtIv5cOHWY7ZD+93QpWxDfqNJeMD6C3CoTHI51gfK7 yd6xXUx2QAjG9rHbxrXiU+3jaKIDG+6IqJPnzNLNh5arzausBXZZckA3f+usxZhxJf4LLH2t9 HB0qSzRXqmG42MxLi4kEdmfGLRnfsk2tY+X/r+iQf5CFvTA== Archived-At: Cc: Stephen Farrell Subject: [Dtls-iot] Replacing TLS_PSK_WITH_AES_128_CCM_8 with TLS_PSK_WITH_AES_128_CCM X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:53:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ooORnte8jwx3gxAcbRxJP9gUMUTsW6Wv8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen wrote: (1) 6.1: Is TLS_PSK_WITH_AES_128_CCM_8 still ok for CoAP? We're discussing taking all the _8 ones out for SRTP, i.e., from [draft-ietf-avtcore-srtp-aes-gcm] because of the 8 octet tag being too short. I'd need to go check if the same issues apply here, but maybe they= don't. What do we think? If this applies to any of the ciphersuites here, it presumably applies to all so I wanted to check just in case. (Kevin Igoe and Magnus Westerlund are involved in that SRTP discussion in case it helps.) [Hannes] So far there has been no issue reported with the use of shorter message authentication codes (also called truncated authentication tags). With AES_128_CCM_8 the MAC is 8 octets long whereas with AES_128_CCM it would be 16 octets long. While this does not help to improve performance it reduces the bits transmitted over the wire. The summary of why the authors of suddenly prefer full authentication tags over the truncated version is from the write-up found in not really understandable. I would feel more comfortable if there is a reference to an analysis given somewhere why this is now a problem and wasn't one not too long ago. My recommendation: Keep text as is. Thoughts about this issue from the rest of the working group? --ooORnte8jwx3gxAcbRxJP9gUMUTsW6Wv8 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 iQEcBAEBCgAGBQJVpM2TAAoJEGhJURNOOiAtkKkH/jyLdfVXAVisphFGv4fV+y0g 99rlgDvScTXhY636Jfa4rWnaJMk1NMYevpMhRvDAiIYK3uxqgRWonMRxXaZcAhOf WodLLpW7Zd3/h6cO2cwOOQL757Mqq5FI2/fbVG3NrtKl92SS1SpMnBMGodAs5Q0G olOqQfpALnFnvTXh5hKtYLfCr0tEH3SYrb8zyCmUbNiMHoxYm5PXCKjtu0voHBY7 fsUcL4j0Kz9fOVRh3sRKwNjYDAYRVmQzgz/b0NCqb88yJiimjTYqQQ3Ryg83cK4K DRc8nzRxjdy1GYSnvrUYn7XVabiRGQSMlyq/oxTzfW9zh4EJlcEDHeLC8h+/e8c= =3kwd -----END PGP SIGNATURE----- --ooORnte8jwx3gxAcbRxJP9gUMUTsW6Wv8-- From nobody Tue Jul 14 01:59: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 B92041A90DD for ; Tue, 14 Jul 2015 01:59:26 -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 c_cStvJLDEDs for ; Tue, 14 Jul 2015 01:59:25 -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 9DB7E1A90DC for ; Tue, 14 Jul 2015 01:59:24 -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 t6E8xHQa007272; Tue, 14 Jul 2015 10:59:17 +0200 (CEST) Received: from alma.local (p5DC7ED13.dip0.t-ipconnect.de [93.199.237.19]) (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 3mVwks14jrzD2g4; Tue, 14 Jul 2015 10:59:17 +0200 (CEST) Message-ID: <55A4CF63.40101@tzi.org> Date: Tue, 14 Jul 2015 10:59:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Hannes Tschofenig References: <55A4CD93.80800@gmx.net> In-Reply-To: <55A4CD93.80800@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "dtls-iot@ietf.org" , Stephen Farrell Subject: Re: [Dtls-iot] Replacing TLS_PSK_WITH_AES_128_CCM_8 with TLS_PSK_WITH_AES_128_CCM X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:59:26 -0000 Hannes Tschofenig wrote: > Stephen wrote: > > (1) 6.1: Is TLS_PSK_WITH_AES_128_CCM_8 still ok for CoAP? We're > discussing taking all the _8 ones out for SRTP, i.e., from > [draft-ietf-avtcore-srtp-aes-gcm] because of the 8 octet tag being too > short. I'd need to go check if the same issues apply here, but maybe they > don't. What do we think? If this applies to any of the ciphersuites > here, it presumably applies to all so I wanted to check just in case. > (Kevin Igoe and Magnus Westerlund are involved in that SRTP discussion > in case it helps.) > > [Hannes] So far there has been no issue reported with the use of shorter > message authentication codes (also called truncated authentication > tags). With AES_128_CCM_8 the MAC is 8 octets long whereas with > AES_128_CCM it would be 16 octets long. While this does not help to > improve performance it reduces the bits transmitted over the wire. > > The summary of why the authors of > suddenly prefer full authentication tags over the truncated version is > from the write-up found in not > really understandable. I would feel more comfortable if there is a > reference to an analysis given somewhere why this is now a problem and > wasn't one not too long ago. I haven't looked at it, but GCM is known to be brittle when you truncate the authenticator. Doesn't apply to CCM. Yes, the CCM-8 versions should stay for constrained applications. (Ceterum censeo draft-schmertmann-dice-ccm-psk-pfs-01.txt -- we need to revive this one, using the new curves, and cut out the attempt to use CMAC.) Grüße, Carsten > > My recommendation: Keep text as is. > > Thoughts about this issue from the rest of the working group? > > > > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot From nobody Tue Jul 14 10:19: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 198671A92B1 for ; Tue, 14 Jul 2015 10:19: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 vSdD9NDXvW9I for ; Tue, 14 Jul 2015 10:19:12 -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 C7A7E1A8A6B for ; Tue, 14 Jul 2015 10:19:11 -0700 (PDT) Received: from [192.168.131.131] ([195.149.223.246]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjquD-1Yhw1s0IHZ-00bofj; Tue, 14 Jul 2015 19:19:09 +0200 Message-ID: <55A5448B.9060009@gmx.net> Date: Tue, 14 Jul 2015 19:19:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s9CwDMP6A0F5B6mAkHMaR05TNtPf2K5SO" X-Provags-ID: V03:K0:EPH3iwDI6dh6JVTLtbMGxwLKWmK0kH8SD4MqMpkGBTe3AYval8n fPRu29lwZU+UGYY00CJygR00X/VKL18iWf1BHYlXOiegkVLslrcviClfLWSqHNeLB47LvZd B0leu4ieOiEIIkeac1BV/yryBXBYQdzF8/gE/6bCNhN5fcvRe4caOBUTTWlsVH2zBQFxwcZ ARnjIlzwB5Lc5IvnfPj8Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:H/5O0dmU3/A=:4NgQ4Z5MSJrpeTqq81vo7F aSBAZeifO0GBi6auBnc/qyxGwza0UanPQmutaH2nGZXqGRzJa32261XRzrn7v/K3XH1Wvp18l uq++l7MEYrrjn09vYVXGomTUZn+xhHVklzFQ33AmAQYkTBp0PGlVuJR4xbBuCIM2lfKan5zEt ZWrrF0vsyRDVZiDKDoIaBjMBLBkpC+ichuEvieFd12NAHFBeOItUuEhiG8nboDXefalS0EhCZ eAYg6L/+54OGaJq6Xyev5d3Ogk6SBWc6vDdaqUErBcUmkInxuSHDXwpYZW1EW7AG+gAhGDZZe QMKp43sBEdyd2fQ18B30LV6D9l4B16B4PCjEU3IwfcD2VzMY0Vqn7RLprn4sEUFn72Ro66WiW auVhGpORkDDKLOiDprIbM1VSxfwEXS4RiO1Pf56XYZn19hsF/WuFk+yyVe08JkKQ2ZInulWhF ik2VU3iVNXl4HDJedvKs1gN6dAb9XjcJu390k7e6AVEYAnWYIbY5LIEF1lRbo0HkGsjZeXvIR H0lePpNo4AdTkDtNZd+x5xAK1jG6fDSRMqEqTOvniuRKkFPjWpvurUlzImuX5RMKaZP28nymg fxLc5xWyfZOSIeU+6PRjt25VJmmeAR4GQVj9lGElMbeR3Jmo+JKjRqSWQ2Zdm0ZmBYIvmcVOk N/+vOwyv+bTxIAH628lulS4JZTkDsPBuHvgwA+e3yE4PZ0Q== Archived-At: Subject: [Dtls-iot] Unique Key Pair per Device X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:19:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s9CwDMP6A0F5B6mAkHMaR05TNtPf2K5SO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen wrote: (2) 6.2: Saying that the client key pair "may, for example, be configured during the manufacturing process of the device" is not ok really. There have been too many cases where the same key pair has been used in whole production runs or worse. You need to add a 2119 instruction here that doing the quoted thing "REQUIRES a different key pair for each device that SHOULD be generated and installed in as-secure a manner as possible." Or similar text. I don't care where that text is added (6.2 might not be right) so long as it's not hidden away on page 54:-) I agree that it would be useful to make this point more clear that there is a need to have device-specific secrets provisioned. This has been a source of IoT security vulnerabilities. I re-read Section 6 and extracted the relevant text from various places and created a new section that discusses the larger issue. Here is the proposed text: 6. Credential Types The mandatory-to-implement functionality will depend on the credential type used with IoT devices. The sub-sections below describe the implications of three different credential types, namely pre-shared secrets, raw public keys, and certificates. 6.1. Pre-Conditions All exchanges described in the subsequent sections assume that some information has been distributed before the TLS/DTLS interaction can start. The credentials are used to authenticate the client to the server and vice versa. What information items have to be distributed depends on the chosen credential types. In all cases the IoT device needs to know what algorithms to prefer, particularly if there are multiple algorithms choices available as part of the implemented ciphersuites, as well as information about the other communication endpoint (for example in form of a URI) a particular credential has to be used with. Pre-Shared Secrets: In this case a shared secret together with an identifier needs to be made available to the device as well as to the other communication party. Raw Public Keys: A public key together with a private key are stored on the device and typically associated with some identifier. To authenticate the other communication party the appropriate credential has to be know. If the other end uses raw public keys as well then their public key needs to be provisioned (out-of- band) to the device. Certificates The use of certificates requires the device to store the public key (as part of the certificate) as well as the private key. The certificate will contain the identifier of the device as well as various other attributes. Both communication parties are assumed to be in possession of a trust anchor store that contains CA certificates and, in case of certificate pinning, end-entity certificates. Similarly to the other credentials the IoT device needs information about which entity to use which certificate with. Without a trust anchor store on the IoT device it will not be possible to perform certificate validation. We call the above-listed information device credentials and these device credentials may be provisioned to the device already during the manufacturing time or later in the process, depending on the envisioned business and deployment model. These initial credentials are often called 'root of trust'. Whatever process for generating these initial device credential is chosen it MUST be ensured that a different key pair is provisioned for each device and installed in as-secure a manner as possible. For example, it is preferable to generate public / private keys on the IoT device itself rather than generating them outside the device. Since an IoT device is likely to interact with various other parties the initial device credential may only be used with some dedicated entities and configuring further configuration and credentials to the device is left to a separate interaction. An example of a dedicated protocol used to distribute credentials, access control lists and configuration information is the Lightweight Machine-to-Machine (LWM2M) protocol [LWM2M]. For all the credentials listed above there is a chance that those may need to be replaced or deleted. While separate protocols have been developed to check the status of these credentials and to manage these credentials, such as the Trust Anchor Management Protocol (TAMP) [RFC5934], their usage is, however, not envisioned in the IoT context so far. IoT device are assumed to have a software update mechanism built-in and it will allow updates of low-level device information, including credentials and configuration parameters. With all credentials used as input to TLS/DTLS authentication it is important that these credentials have been generated with care. When using a pre-shared secret, a critical consideration is use sufficient entropy during the key generation, as discussed in [RFC4086]. Deriving a shared secret from a password, some device identifiers, or other low-entropy source is not secure. A low-entropy secret, or password, is subject to dictionary attacks. Attention also has to be paid when generating public / private key pairs since the lack of randomness can result in the same key pair being used in many devices. This topic is also discussed in Section 14 since keys are generated during the TLS/DTLS exchange itself as well and the same considerations apply. Let me know what you think about this proposed change. Ciao Hannes --s9CwDMP6A0F5B6mAkHMaR05TNtPf2K5SO 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 iQEcBAEBCgAGBQJVpUSLAAoJEGhJURNOOiAt340H/0SFLmh7zTKBlNRjbUwLyAFa dPdMDbwdX34ZnfvxtFfjhu6falJee7GsA9KmaFUdeiUE9TRYRQ/apiaLocpKuDra DvgbgIeHwdSzp0ccd7hWxcAX8wc2VQFdO+7A8SeHcUxG0tWWwM0VBZRo0DDc4i0Y x8ZwZaHc3kF7LQ5YQBJeF6rBDzOWQErIQnrHj5SrIQg1amS/6PKOMF0KQaG+oM4E Dzb2DIHZMVLTXTfTVv1qW+46cHse+SXEffR3Sdq7qn8yGgDcYh+k4UW0++BURSVO EjJWohXxI9/CdcEZ+icXHKm95LHdWjFxmEEbvaA18kQBeaqcLHrbEgW9UhSxlHI= =pVlO -----END PGP SIGNATURE----- --s9CwDMP6A0F5B6mAkHMaR05TNtPf2K5SO-- From nobody Tue Jul 14 13:39: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 94E761A8894 for ; Tue, 14 Jul 2015 13:39:39 -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 EeQySegwsOML for ; Tue, 14 Jul 2015 13:39: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 9402F1A888B for ; Tue, 14 Jul 2015 13:39:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B2B2BE50; Tue, 14 Jul 2015 21:39: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 kaxsDUcF6Jhq; Tue, 14 Jul 2015 21:39:36 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 43F89BE49; Tue, 14 Jul 2015 21:39:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436906376; bh=Ff5BPrgKFX8ZAgXJMGYSWFPg4zCtHnIu0tB1G1sQ+PE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=SHvjzcfNmEw3vVY3WjZ93biE4I9Yexow+/mXcjQuGgMju+sY5w3xFRG5cGXFRCo7N OTMG3ttLbc7Bj6sm1a2rEOsMHnuE9LcTm8rqJ7zDgd1xbjYwXVVOYIrKCSFnW6qKLT QMUg4NtWWRp8c3pK6Wx579OuVwPOLUwD/a3INC/Q= Message-ID: <55A57387.80100@cs.tcd.ie> Date: Tue, 14 Jul 2015 21:39:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Hannes Tschofenig , "dtls-iot@ietf.org" References: <55A5448B.9060009@gmx.net> In-Reply-To: <55A5448B.9060009@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNbA2DqR8GMJ0hoRTIxKwlnvd5ColJTRF" Archived-At: Subject: Re: [Dtls-iot] Unique Key Pair per Device X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 20:39:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cNbA2DqR8GMJ0hoRTIxKwlnvd5ColJTRF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/07/15 18:19, Hannes Tschofenig wrote: > Let me know what you think about this proposed change. I like it. Only thing I'd suggest is to maybe say that you need a good source of randomness when generating key pairs on-device. And maybe add a reference to the mind your p's and q's paper as a counterexample. Cheers, S. --cNbA2DqR8GMJ0hoRTIxKwlnvd5ColJTRF 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 iQEcBAEBCAAGBQJVpXOHAAoJEC88hzaAX42i8ZMH/2sr3YtW8V1uFnm7+t6TyRIE iarLKWSVv8MhUYxiBHm4NBB3T+t2LeKCR5tmQl5uqOSOSokUMya0CaNtQtSloWo7 ftVTaI3mHpX8nAMI+nV6q3h3rMkNIjPs+AA7Sa8uA9cByhhzkbD8j+BfcFzbpvP4 xyBsRFADiqTP9sGH8sWE92q1MSKUk4ZBAtr+NC5pCH6jbQfX483QQLn8umJ3KWDd bg/GtoLcN+6JU9eU5JDfqB7rCZQXyzrybrNnXkQbgt47GX/rCz2BX3ZERcUWefG/ X/feMh62UmNfIFcuYTcfjFYpgm8gUtJc2R2Ws74fNfW3w9d0wHGkXpkmM+YiBf0= =rvcT -----END PGP SIGNATURE----- --cNbA2DqR8GMJ0hoRTIxKwlnvd5ColJTRF-- From nobody Wed Jul 15 01:07: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 A05AE1A8848 for ; Wed, 15 Jul 2015 01:07:03 -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 gp7JGPWBrmnN for ; Wed, 15 Jul 2015 01:07:02 -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 A1B4A1A889B for ; Wed, 15 Jul 2015 01:07:01 -0700 (PDT) Received: from [192.168.131.131] ([195.149.223.246]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lwoiq-1YviYq2WEa-016RXt; Wed, 15 Jul 2015 10:06:56 +0200 Message-ID: <55A6149F.8080103@gmx.net> Date: Wed, 15 Jul 2015 10:06:55 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , "dtls-iot@ietf.org" References: <55A5448B.9060009@gmx.net> <55A57387.80100@cs.tcd.ie> In-Reply-To: <55A57387.80100@cs.tcd.ie> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="spp0UoEBjlob8fDs2B7vioNglXwsgC8Fa" X-Provags-ID: V03:K0:eVMmwxAzyiXzg9ZcyYKXi+xWJ3TR/5++6NO3+s47FQqEEbWx9xm YAraWGj5nYBDrYR+zeYp8CnJ5ZkPmBVxVAJN6VvF3THVcEhthXCg6Bv4gB4yENX8bqPAK7P mQhI2acBTxsKa4WzCzpC0vSyZIajFhgj6QnO7HKgFbMUFOMKxwAem1sSvlsHPIpAQ6KzRXh 9vVY+TzdAuILuZ7VV6oww== X-UI-Out-Filterresults: notjunk:1;V01:K0:kQzlXMdYGvU=:gtfxpcKz6O1j1mjeWv4UYq FEhK99w+n+eodMRuq8U+GxiGl4TqferXtXtQFuN2dgxV+qRXz7V6NHeGMOE8RhTLQ2VBWTGCn NPKeEunU7C7uCRMKMBgwtqjlQtwfclo+s0U1nbcRk1CwWIycAYk9E3Qj9Exh1b6MRElPHEAVf VUE00AzLC6TKG4765ecxOKHYcKOVvRPynWRovyeTqwbb0Tv4VTJrj3WatN0ci8vEvzhM67iB6 NjxllccJvvo5K9o7fvq8Fn/4mMWAwIgFI8+mVpVuVeF3rFQSagVfiI1huprgGK1a9da0qNVAi 9H8kRBtwJ+WaJWKxf5RwgTgdFt+UtE2S6D115YThAc+zBDNl1VrC09z1G9eBgkLhdDVk2OP2G STwqG0kKEN2/JfeaMA1e+ctxybz+y9PPpahUthFz0XVmr+Y0UzfFpd5cczQCmez8p4X/oKgFL 3y5hFvAUeXTy3qwu2XTcLwVrJUeaLoj6wtgpAWUpMqNxZroyItTZErQri70VUiBTrLpevEGrB ulPlT8h/s/juNuJW2HSL1XOpQGdzBh72lkG1R/CtJGONemvOkuXMKVh6lc6koLO/saJFw3EQ2 wi/PMSh8Mew3j7AC+f0qAZm3Qq65iHdzBMgH0ymDySBjCComx0bMLE9PESd9ZnhXseD2WWuZm /48lhK1fUmQW8WzEUBmw67Mm3gd4MHPkhf8vOUGl83bI+Iw== Archived-At: Subject: Re: [Dtls-iot] Unique Key Pair per Device 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, 15 Jul 2015 08:07:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --spp0UoEBjlob8fDs2B7vioNglXwsgC8Fa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, I included a reference to the randomness section where I discuss this topic in more detail since the importance of randomness is not only important for keys provisioned into the device during manufacturing but also later. On 07/14/2015 10:39 PM, Stephen Farrell wrote: > Only thing I'd suggest is to maybe say that you need a good > source of randomness when generating key pairs on-device. And > maybe add a reference to the mind your p's and q's paper as > a counterexample. Ciao Hannes --spp0UoEBjlob8fDs2B7vioNglXwsgC8Fa 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 iQEcBAEBCgAGBQJVphSfAAoJEGhJURNOOiAtydcH/1sK5qh50ZpswiUev/PNk157 z8rNkaYdPPJPcyOv1DFbpkSqeOyWXQ2ipjt9hnKLHaLtRov4iolGniEUFAcRpe62 7oRJ2JUBU7iVHYYsD5mbH3eXdRE1C8oYcvOnogVvJTr75AJcGr0bbRDHVmoXyl+P qJdPkFTbxWL1Fw85nen4lOUvIruXh6TIbSFrJ1NDpTDv0t68SGWS8vvaQ7wCJG+p 99oEPoQ1ovkoBBP0ojgoXqfHLgcOcZ5m6mRMVX0m5bSHqQPKj9O2/kwI8f4Ua5XI rnnJdTAh2OKCFovjmlub8Tcc4hi2+98gvNHaBx847X8VbwFCS7wVukJ+G3toOws= =JMyE -----END PGP SIGNATURE----- --spp0UoEBjlob8fDs2B7vioNglXwsgC8Fa-- From nobody Wed Jul 15 03:58:09 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 5E3D41A1B4C for ; Wed, 15 Jul 2015 03:58:07 -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 DfOu-8tkGFhM for ; Wed, 15 Jul 2015 03:58:04 -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 7525F1A1B49 for ; Wed, 15 Jul 2015 03:58:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 539E6BE4C; Wed, 15 Jul 2015 11:58:02 +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 hCFe1jQ0_9o7; Wed, 15 Jul 2015 11:58:02 +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 21394BE49; Wed, 15 Jul 2015 11:58:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436957882; bh=FjdwLAjLY5yUUMcF8yOCYP6UGlkEbRJTeBUv1t5+Alw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kayNk3Ovt7S8/OFljBdXhQb51YeEaWvDlkNikEiDpKsU9w0ZNIkC76jRi4JZuiHBe EcW52TaI9p3CSBWOx5o12ZwiIFibjLnTUlpjnkFznMFhPEC/Iv96xhDWfD3UF1atV2 uLxj6DHULO0UYpZaP/jL4up79DS8CaWFQ1CU1Mls= Message-ID: <55A63CB9.2030008@cs.tcd.ie> Date: Wed, 15 Jul 2015 11:58:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Hannes Tschofenig , "dtls-iot@ietf.org" References: <55A5448B.9060009@gmx.net> <55A57387.80100@cs.tcd.ie> <55A6149F.8080103@gmx.net> In-Reply-To: <55A6149F.8080103@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DTJhSd4kKjaVj4bMPaqVBoURcdV88K9CL" Archived-At: Subject: Re: [Dtls-iot] Unique Key Pair per Device 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, 15 Jul 2015 10:58:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DTJhSd4kKjaVj4bMPaqVBoURcdV88K9CL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15/07/15 09:06, Hannes Tschofenig wrote: > Hi Stephen, >=20 > I included a reference to the randomness section where I discuss this > topic in more detail since the importance of randomness is not only > important for keys provisioned into the device during manufacturing but= > also later. Works for me, thanks, S >=20 > On 07/14/2015 10:39 PM, Stephen Farrell wrote: >> Only thing I'd suggest is to maybe say that you need a good >> source of randomness when generating key pairs on-device. And >> maybe add a reference to the mind your p's and q's paper as >> a counterexample. >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --DTJhSd4kKjaVj4bMPaqVBoURcdV88K9CL 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 iQEcBAEBCAAGBQJVpjy5AAoJEC88hzaAX42itgMH/0ZVrNnBXj8rL8uhqxlChZk7 zNrvQNpghKMBGdqZBJ2yPbp4x1xjsjwpBY6CeNXxQak5pmCsNXMJPPJ2q7p7sjUt RO6ROnDVFdw9sFM1iAtaophczltjL5w5yYUWpqjux7HRmv2Fcgmg4KpJFejUMTo8 RwZ71xMvGuE573xomKqUcpMA5OsNg/HWGpTIEondBSGBSeY61vbDwCVjXjfuXWWT sA15TAeLU3nOaQ13br3RtHyarAb1osBR3x3Q0tz9BQEPg1aqzZOY0m0GavzN5/rM oMJ63vQhOMSomQcYiprzw5f5mcjB9cYZqdpkNXu21BNv50tC2XOpfXp5YB00H34= =JOwc -----END PGP SIGNATURE----- --DTJhSd4kKjaVj4bMPaqVBoURcdV88K9CL-- From nobody Wed Jul 15 03:58:35 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 CA00B1A1B4C for ; Wed, 15 Jul 2015 03:58: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 XgDmPs281bs9 for ; Wed, 15 Jul 2015 03:58:32 -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 1F6901A1B49 for ; Wed, 15 Jul 2015 03:58:32 -0700 (PDT) Received: from [192.168.131.133] ([195.149.223.246]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3S2C-1Yxw053uOe-00qyED; Wed, 15 Jul 2015 12:58:30 +0200 Message-ID: <55A63CC4.9030006@gmx.net> Date: Wed, 15 Jul 2015 12:58:12 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MDKeM4LfvgdCR032FWgdI3dvpT37LFPaf" X-Provags-ID: V03:K0:8caBZgoY2w3f2IBPhFluyQP/QL+ucHX4rCQSDZsbpbMn3sykdne ZpjPQ9Opn/YvWwmulVMYTDa26FJ8rR4fbguwnebUH9/jnEWM4wCMAkZ7sa0ysABDsGK36uB OEK6thHejZ2flyrKcwURhnA/8oCcPXsd+qFFqJwp1yAZ3sGpQR7ck3wXzeDonj58vk9MS4r SNttAlHEYbSatj8fFxgmw== X-UI-Out-Filterresults: notjunk:1;V01:K0:6B++3nzKkpc=:XwnjGeFMUSNxfSxAbGxgwC Xc4jMn2st4P1t9lT7NMHnSfyRlgQ3VHrUB8h5kEwMjq2VJcbYy6Yfl8FOIv2u8M5x5u8IriCS y0v5FI3R0h85TuKnkCMkm94O4TRpOIatu5Ez9RqBye4Vb34j/Wvjj/PwT8bIojq85hqDkbWFU Crq9M8xNIz7D+5Smn6oxnBT0crS7WGehhB78Jye7PiEAXV9vvR92JPNNdBC7lG+Xw4HcagqPP jUrw9HfeEmEybTMb8z0vVYpzPEUeMz+7S15zg1RovDSQhlkIGD5fpe1glirLB9UQnI4g1h2VL aGCkQf5shWzUYrZbFS7QAwec+d+N9Y3Pf4K2RuCBfNabQkLlEC0exqsejECFsOZalCG2FxPeZ /6QDLjx9s68x4r6rIIzviCb6EaN9FH24UpX8DTrsScbMreu46cbmDcci5PrzT0J7WHfEt6J3z Jased29T3F9Qig7yXKLp/CcnoUZv63u7FdyO8Ngzp/OO6zW96T4n2n9w+6yG65hKmBALxvoeQ e/7HNXEfTKRl1o22PVicsirG4xT+IGojhbkX+g938ClXezwbh4aUndGzia+KXOj8f1DXWdXFI tbu/qJDsDeI9j40unZenNJkC+sXC+M82+J6RRBOQqKXdNx1xMR/Tx1P/hjfyiZl+aoXKaIxT7 ftqWwNwGIcBE2TzfOfaxv9iHajzEP2LoEwirnq/CxXzQ34A== Archived-At: Subject: [Dtls-iot] Ed25519 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, 15 Jul 2015 10:58:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MDKeM4LfvgdCR032FWgdI3dvpT37LFPaf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen wrote: (4) 6.3: The Ed25519 reference should be removed or the text modified. CFRG are not selecting Ed25519 it seems so that would be misleading as-written. In this case it is best to remove the sentence and the reference. Ciao Hannes --MDKeM4LfvgdCR032FWgdI3dvpT37LFPaf 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 iQEcBAEBCgAGBQJVpjzEAAoJEGhJURNOOiAtZesIAIxiJf4cx4FbwKtqBneNY/QK +e/kHSsUKl9daOJ+/nmFjfHK8nwWafZcABujIs9ytYfg1SoJPcLm5G6miCF2TGc5 vYdvbsGJ7gAwrzKeiLQ/4D33n0eyGLYZfa2h2SzahavtgAMRtT5M+HThlpnHsHvy DQvS/dzzLZSK7ekkJu8AT6ouZp7VTeTPeHMwKpARJ2CQZ1QfmoKrx2gf/D8Q9Z6J 6NvL+Su+g3pG2+U5iF1TLQ/3qixh5p112w2K5+joWFXWG+95IoJvBSJHvPrtQFwd Gf86hgzkr/36hcnA+vmzFccPjPVOdhAZNFAnRDLDDZE/cxJd93BIAMeSl+cZPzU= =YDdn -----END PGP SIGNATURE----- --MDKeM4LfvgdCR032FWgdI3dvpT37LFPaf-- From nobody Wed Jul 15 04:08: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 7F26A1A8709 for ; Wed, 15 Jul 2015 04:08:37 -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 cR5cQdNFm9Gy for ; Wed, 15 Jul 2015 04:08:35 -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 8FF851A8945 for ; Wed, 15 Jul 2015 04:07:30 -0700 (PDT) Received: from [192.168.131.133] ([195.149.223.246]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjZn2-1YiScq23ZI-00bXPt; Wed, 15 Jul 2015 13:07:28 +0200 Message-ID: <55A63EEF.7010608@gmx.net> Date: Wed, 15 Jul 2015 13:07:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="acQiFwHFvRKn8cpispmiKhWG0mcvRUSVq" X-Provags-ID: V03:K0:TE/bBVIzNAi2O7iLRZBQ0q4/0SBJmtdpFysMa2AsSMMNdJbU1wa GXPG64iCiLIRVNtoj5MREux54nEigrW0lQj0LMY2HtluiiTXDQA3JwINEzv6NyyF+7efyyb JtP4IzPfvslQYzO6MEJVCZN8kuhU15OZjaF1Fghn8q1SYuQUdF5oYZvH0KD44tcjBZFxofR E3IF7hf7PCV4JKzftNElA== X-UI-Out-Filterresults: notjunk:1;V01:K0:l1n+ZwrUQoQ=:bcFqzOPGs+MY5kUxTnVD8e udGirafGZQO3V1aiqaEj2pco+sPQ5AEUNoMS/aBiIG0kWy7ha9uvp0zTf+9mTyCcJh0nT4Ims ZyIoFoHLw2BFDUIhFIJ6x+3UsA6xMJu8Xqhuyvlshdz1d9Psc6rqFzS9BD2pcEMFJXModSd3c 1+wD5vZXjOt2wMnAfws4ldx33z4g+eez9+5mDqgSrYzuSx4Yktaqg1mZe0zqavrmvlnwuuI6o 9sUkda8ZDVpqOseVmMKlpM33vvm4ucQD/F4H2x48R4YVnPAbmtsJbopu5FhWwo+rzzScTcMPL qh9at0QZdKYbUS8FEzICeU8ZnwpaUUxa/AkFcvbkg2ont/oHlLY3F6wWAnbCsO6Fubz0ZIGw2 q0yAAcpjwKnopfIFJYUFIJAWyCLVk8gorrBwOQ2bV1gKbe7m7ArrT5irfmIZhwNaEwApT88yt K9clKof8ifYBMyE+AQHFLNr6lYvsSiYciau1yBWVSNNoFDSv6WvqJCSF5DKXKncxMesYwU7Bz nsYrh7f72IPMKH7AcnxTnV46nj3LN8uWTrnduEPBesUUDZ2mqYezWrjrkHjdf8G5tXcpX2m14 JVzMi5tfeTzncoj9/aaxRLKaKzHFJceFyAq2h3fNMtF770kCtcFAAy0orQb6LtPlpiRE086pM rs4c/sb3E/U8t0LsrGapHCkiOTAvuxDpjjv/+WTClRFizVg== Archived-At: Subject: [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, 15 Jul 2015 11:08:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --acQiFwHFvRKn8cpispmiKhWG0mcvRUSVq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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? In general, it is not clear how server-side certificates work with IoT devices that do not use DNS. This motivated us to write a separate document about this topic, see =E2=80=8B https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-01 For client certificates it does not really matter that much what you put into the certificates since the content is only matched against an access control policy (without further interpreting the structure of the identifier). So, are you talking about server or client-side certificates? --acQiFwHFvRKn8cpispmiKhWG0mcvRUSVq 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 iQEcBAEBCgAGBQJVpj7vAAoJEGhJURNOOiAtFSsH/35U8lXMrnKxNq8l/urtL2yJ QDfMZtZUsHlTZioimYvWypGfHsuDxxZlwO+e/Z8kZFcp4E3oj047vXp9no2PPYsp FLyp84EI1cW6byjlm6/eS85NSeYJINQHQ5zZmRTUNibh37FvcsXbeX/g7KtF1MqK 7MlYOfHDQtKMj1QnahFAXmcrEb4VT6cb7RBHlQmMBgiBiAjPp/kzDGttquqtVrbL +qLtVMUDXtzDbg/hZMmLCjo/BARWNEZNfk+TjJ4TYGEQFXioXB2Cxi704DaWN+fF G5nc4j9rUEkeWOGSbL78xuo7Owgspqfrn1y89SPfx5VxBTDUlcNw8ur14PIXZro= =3MhY -----END PGP SIGNATURE----- --acQiFwHFvRKn8cpispmiKhWG0mcvRUSVq-- From nobody Wed Jul 15 04:15:42 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 3C0B21A8702 for ; Wed, 15 Jul 2015 04:15:41 -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 iwIdrb_ciW3d for ; Wed, 15 Jul 2015 04:15:39 -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 4119B1A8028 for ; Wed, 15 Jul 2015 04:15:39 -0700 (PDT) Received: from [192.168.131.133] ([195.149.223.246]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LoE4f-1YnAm141mL-00gEl1; Wed, 15 Jul 2015 13:15:37 +0200 Message-ID: <55A640D9.5070005@gmx.net> Date: Wed, 15 Jul 2015 13:15:37 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wkCoq2M8R4Hk5GScaVtrfpXtrwTJoGn9t" X-Provags-ID: V03:K0:gNe2tOWr4nACGHFU0jRuz4rjJ0Ug3o0kdjy7Zmt/5fdP/gWQqUy /nVzFjkURnh7OrDq1ktof9+CKaGEkzen3jF0yYmbD+96m/9qrrcsNPcZvyYtCIrnDofncQP O23gmignTJer1pRfWHc4RIM5jWq4y5Njdml0gTr0hw5lNW+O/zD3H6nljPpaoT6rLfz1DRt Gw+nEI1M+01dJs/tQE7vw== X-UI-Out-Filterresults: notjunk:1;V01:K0:n/T39pEzGoU=:eFgtnZ5crMJVXqqWQ1CdKP 0UsDzLsPIRRILdBn4ceuAyl7n/oSENHTVOQgc2cKRaTI1NvR/WAdcLngSBTTyjQfgZXXiRlwQ ZUlgjiCpWB3M1ypJYNBWnqHR4YopPlta66Htb9BFCDr+RM21P1E/bhjBoeSbHG6GbPCmNr9J/ kVysdCfMNNWtyHhTEcTnsaaG+Bi7yMQfJ7ONKwMkKeY3pgwF2P823Rdv0H8tBN5oLHyqRZClS W6+mTWOv+rpE3GRE/GWPmiQFqrp5aIT1hg2M7q/5aQHmAT5Kgj5kX2q2oekOOGnKUTZdX5I1Q 1FQp45E1CxaHa74X0LaNgV/HQ7ZDfd9h3WHrK2yciHfKG3TyKg3mnWJETWmcvBP2yhdabazdR 6ElryZOE9f1kfGtKlu5fLT0/SaPF3IizN3cdzCXBiUEJksdHqP+Of5a77TSQdWLLLJUOsS6GY OrmNUc3c0/q/NIH4ie0eSXBrEmLushM94b3PVlW7BnoPo7HTWUr3OZqMv0z05erPE8oIGpBVh Dru/w4GIc1EU14yjBW21Rwx8khCptYRvAJCkKf9lJgKjG22cC0CiMO6e52Dyb7TmOpXZfhobj dtB73hzgq2khsKXhc018Q9F6fwe22lvTt8/Xo5eDVfaexgl7uXMbzfsAZbk1HkuP8sQYfeyJs EzL97jI3GkP+t4c0u+HsGEd0O88JlilFWKeGuBvpSOvmSAg== Archived-At: Subject: [Dtls-iot] Reference to Heninger Paper 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, 15 Jul 2015 11:15:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wkCoq2M8R4Hk5GScaVtrfpXtrwTJoGn9t Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen wrote: (7) 14: Doesn't [Heninger] really cause many devices to use one RSA prime factor? That's not the same as "same keys again and again" and in any case you're not recommending RSA keys on challenged nodes here. Shouldn't you do the analysis of the impact of a dodgy PRNG on populations of devices that follow these profiles and not something else?= Heninger did an analysis of the deploy infrastructure of that time and RSA is in widespread use. Hence, her analysis focuses on the problems with RSA keys. However, her observations are general in the sense that a non-existent or bad random number generator will lead to output that is predictable or the same with a number of devices. This is essentially what I write. Copy-and-paste from the text: --- Special care has to be taken when generating random numbers in embedded systems as many entropy sources available on desktop operating systems or mobile devices might be missing, as described in [Heninger]. Consequently, if not enough time is given during system start time to fill the entropy pool then the output might be predictable and repeatable, for example leading to the same keys generated again and again. --- --wkCoq2M8R4Hk5GScaVtrfpXtrwTJoGn9t 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 iQEcBAEBCgAGBQJVpkDZAAoJEGhJURNOOiAtl68H/3kJ7x58l1kUPH82VMdJxBcC M1NxniYYd+/WN+Te7rnbdM0JDkH5zDT9NxtT0U8AKG6p1bTmm5nDZTdLdO+tn6yN g4gqjXpgsjIw3lilu6E3IxWDms/9zQDIKmfKkC5+PP6e0ijTITkY6QoMVG1jw7dR Gd5yHtT3BRsskGsDlfpIU9ZQmScdHzjS3MMPF/G+mms4hB/uNaRi9A9BJuRO6e9V D7b02hSydEeU3bXtIhwFGPXzR0BUvpvX4ZqVDekIGC5WDqLvRux1teZGD1WtpX/Q 3XDP7LtVdfOguDyr/3ajC1Xaq3JqNqzird/UV/r2jjf4MLASn8MMlKCj3pvJqiU= =z19n -----END PGP SIGNATURE----- --wkCoq2M8R4Hk5GScaVtrfpXtrwTJoGn9t-- From nobody Wed Jul 15 04:20:18 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 7DE2F1A8838 for ; Wed, 15 Jul 2015 04:20:16 -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 QA-W0Xnw1XQi for ; Wed, 15 Jul 2015 04:20:15 -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 BED711A8835 for ; Wed, 15 Jul 2015 04:20:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 997FABE54; Wed, 15 Jul 2015 12:20:13 +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 Ld11Qx1cWkAB; Wed, 15 Jul 2015 12:20:13 +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 572DBBE53; Wed, 15 Jul 2015 12:20:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436959213; bh=GE7BYLtB3PuDzI6F/C9+ZbKO0WLxY7tMLpO7TLXov80=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fA8ssXNG2wgryxmm/CVmWSHGkr3sLdXLDjfbs9b1rVxeCGVZ6nz3lQHJBy2Ny/gIE kuGH004yPeOVAFoUj0dn2Z1KLelY2jLs50Jvd+WiNhowQ4r6Yv8/1AyXY5zbyqWd3L N1ZtnMa8OtWwFU2xC7MdYqbqq0QKrqI4t0b5Ewyw= Message-ID: <55A641EC.4030203@cs.tcd.ie> Date: Wed, 15 Jul 2015 12:20:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Hannes Tschofenig , "dtls-iot@ietf.org" References: <55A63EEF.7010608@gmx.net> In-Reply-To: <55A63EEF.7010608@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oFaGDbvIIKvjgQhEpB5d9VBKL4GmnR81D" 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, 15 Jul 2015 11:20:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oFaGDbvIIKvjgQhEpB5d9VBKL4GmnR81D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/07/15 12:07, Hannes Tschofenig wrote: > Stephen wrote: >=20 > (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. >=20 > In general, it is not clear how server-side certificates work with IoT > devices that do not use DNS. This motivated us to write a separate > document about this topic, see =E2=80=8B > https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-01 That's a new one on me. I can see where you're coming from but IMEI's in certificates is pretty iccky, even if it's only for a sensor-with-a-SIM device. So I dunno if that's the "right" or best answer to be honest. > For client certificates it does not really matter that much what you pu= t > into the certificates since the content is only matched against an > access control policy (without further interpreting the structure of th= e > identifier). >=20 > So, are you talking about server or client-side certificates? (D)TLS servers mostly. I guess to the extent there are devices doing TLS client auth, those too, but I do agree that in most cases there'll be another identifier used that isn't an IP address, so the (D)TLS client side is a secondary issue. S. >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --oFaGDbvIIKvjgQhEpB5d9VBKL4GmnR81D 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 iQEcBAEBCAAGBQJVpkHsAAoJEC88hzaAX42idw0H/0YZDpZqXIZjP0E6bD3SAXXW jxCwcMqe5IqssjGBDQUPSjzocM/o/MuX0QGXrjbtswbea4TMdWo7lPTVev9+UK8w JqrhxnbWjijKhCZ200JpoyVorIfY20k1rrfs1+7VkqE3XmqLxvxUEOC3iClYqXFl IsK2E6Z9ovr863+j6rlGsJ9FiOruqK7D+qp7tv03GR5Uvubsf34IgD1j8FDYDugS vN18YizPrHpbWfFazH/tcdiEktdqfu82BGgkPqvA5xk8J7PqpqIVj4H9TsoFR+2F 3TyR+2BbyxjdOkNxMCPF3SK+RowQ8A289Qxt+r7/bxXuobH20aTQdG/SAB3EfNs= =Bew4 -----END PGP SIGNATURE----- --oFaGDbvIIKvjgQhEpB5d9VBKL4GmnR81D-- From nobody Wed Jul 15 04:20:58 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 BB5731A883A for ; Wed, 15 Jul 2015 04:20:56 -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 yCbGdNGUlak6 for ; Wed, 15 Jul 2015 04:20:55 -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 DB9931A882E for ; Wed, 15 Jul 2015 04:20:54 -0700 (PDT) Received: from [192.168.131.133] ([195.149.223.246]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LoEwL-1YnAvV3ZsH-00gILf; Wed, 15 Jul 2015 13:20:53 +0200 Message-ID: <55A6420E.7040703@gmx.net> Date: Wed, 15 Jul 2015 13:20:46 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5nlE9iIOmR0BXLaG27mFu3vH7Kp2pwTb4" X-Provags-ID: V03:K0:8cjDwvJnny0tChLAy/K9/sgG8GsXuolmi9nOFOdHKjSF40ZaKoV BqiLn3i4hKfXCFwmea/aAVqZ3QRmsWR5INkAigOhZWOJOTdrAI1GGKVhF/6ez+vm1unDw2z hHEUjbExm73CjgZrXFbLxWjIRRoMZJep156CCJC2miSpXTZDVTFRo9vIF67hvZLkfajNveH bOzBwPB7WI4FDWmvX4byQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZX0aSL7QiSQ=:Q+ubnpta4K5SflCco1p7Zb MVuGETA4GzRXYCSY1kpfKWu9w/cZu8eabxWThZ1+HvWt1euby0e3SpajEaUQKdfhLRgM0SIOS N4XEs+ve1h8kdFi4yYD7Y+p0HsV6B9NHRUHPNLkcFZwaBlpUmOPTwMtFPXD2BVH+AF/CUZH6q D+v54BcXUJjgK0pcwyuc0F0J10f2boAzTfJW6MCNRd+32VjPNQI86T/e6sM3xmnLEKasLvHxV 8yWAzgT/mi2D45mvhphmWWKYCyb/5TiGzp0ApMGmTEnOu2gEooqLDTGvNshCixcZXJidgLjQ7 dEIDn5PvN3HJsRMjv/qe04GcULr+WZPf+uDrO9W7ksA1WqOL6LM5a/yZ+JigsEqPsxcfFiivr MVuOLyQvT51g2LvBfuZxf+9rXPhemQp+1M+tE5i+7Y7qEV+qOt/GqJgk47gnnj/IJ6zDKRPDK CZr2SxSqoDfvIOOsNcl163kz5aN6v8OUwAUpqlCr1jtWHiEbmKTIoKKkO0QXoVTQgcLi+SEuo /RB9/6O10OyA+GkXlZaCJW0z4+whdLzmfV6SHTQlcfbfX7QofaXT1r907Y4ZHTYLmiMrimMui ZcHijzER5GpKIwkMUVbyDJaPi1Y5nGih9BRfkPmH6Z96kpflZmqHfdsygPXHbfkjjTvioyunt qIV9s9LRcdCXlMyOjOrnjbZ6CL9Kle+OzOS8VvQLZbXuttA== Archived-At: Subject: [Dtls-iot] Reference to mathewson-no-gmtunixtime 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, 15 Jul 2015 11:20:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5nlE9iIOmR0BXLaG27mFu3vH7Kp2pwTb4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen wrote: (8) 14: You are RECOMMENDING to follow mathewson-no-gmtunixtime which is fine. That however means that that's a normative reference on which you need to wait. I'm fine with that, but the WG may or may not be. I was worried about this issue myself as well. I was hoping that mathewson-no-gmtunixtime would have moved along at the time when we get the profile draft to the IESG. Obviously, this has not happened. I see the following possible next steps: a) Remove the reference to mathewson-no-gmtunixtime and point out that somewhere a secure time source needs to be made available. b) Copy the relevant text from mathewson-no-gmtunixtime into this document (with appropriate attribution). mathewson-no-gmtunixtime cites a different motivation for doing what he suggests, which I believe is less applicable to our scenario. c) Work with Mathewson on mathewson-no-gmtunixtime to get it finished. The profile document would be blocked till that time. If you ask me for a preference then I would probably go for (b). I am not sure it is, however, in the mandate of the working group to define TLS-specific functionality. Hence, I fear that we have to shoot for (a). Ciao Hannes --5nlE9iIOmR0BXLaG27mFu3vH7Kp2pwTb4 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 iQEcBAEBCgAGBQJVpkIOAAoJEGhJURNOOiAt92UIAImm8oxH3YX9cPiVLjHFd6ek pS0/0k5Xc4FV9polNhwpVdu6fXtXXdRsIQLFpBLBtXSpgBEnBFFBFYIADqYdB01p es/0PZ3ItDaZNYQUEjlg4qj+M0UXHnhVSJjanYq7+8HNVh2rgK46tcC9+u7uoa8F bl5zvPtaO/QFb634OQs8R0YZlnGTKIUKOCo4RnNNAfxqM+Jf27ptyjchZ2abn/ha G9/3zjfQ28mQt/6EnzOGSEY95T0+WRYR7QFxHJnGmPCFgrtRG9uyjhqj3EmYV4j0 jjWW2hHk2KVjw4brJ8+mBs5JEftXz826TtdGPaeGBAQd3MzPC8A6KCD2vqrMmGc= =/sVX -----END PGP SIGNATURE----- --5nlE9iIOmR0BXLaG27mFu3vH7Kp2pwTb4-- From nobody Wed Jul 15 04:23:42 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 C08E41A88A7 for ; Wed, 15 Jul 2015 04:23:40 -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 j-YVXtcXnNCM for ; Wed, 15 Jul 2015 04:23:39 -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 296A21A88B8 for ; Wed, 15 Jul 2015 04:23:39 -0700 (PDT) Received: from [192.168.131.133] ([195.149.223.246]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MeMOx-1Zc7OQ0dNn-00QG4C; Wed, 15 Jul 2015 13:23:37 +0200 Message-ID: <55A642B3.3070708@gmx.net> Date: Wed, 15 Jul 2015 13:23:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xohxe07uarqlX3QhTCJrHVjluagQcM6MD" X-Provags-ID: V03:K0:/0c7i3Z346LLcS2BK46l1gdu9ojNMwxXK78RDbON6acDaxX2Qy0 LinW6uyATonucP5LNMFzeCJS1nLmLGH2CKhEa2YupB9k0NSuX5MGLSYNF5GhAriKlTg3MuZ mnLfNeWB8SVfjkAZswUIMrO7FYy8u6ML3MOEurhzkpZG8M++7j0MEwJVVdMjVm8+g97Q6nr bseCJvdI2SV5+CndkuagA== X-UI-Out-Filterresults: notjunk:1;V01:K0:z0emlpVuYLI=:3SuQfyocjfqMo72VMf0BPm g+MoqLe7VFV5w6j8fCZD97wscwSwZMfEGBtae3Ya2kHowZOkrcggh9PbQPvYYH7MEvrc7qZsu EvdUvnolSM+GYMmhU2NGmBAkkTDWKIhWN0sOgg00MdzhRvJW2fH8QGrASgxK6rh4+aPZ/mI4/ 2zPmOkY8v+Hwn9yQFhdaJNQYyp8GwbBl6Koo8Ex24YWWq7d9gOla5jWo4/9/MjP17UjxsXygj VDNczoT0OeM3axnKc4PTc7+DuuNBVXuHxhuty45c85s7XHYNwO8NqH5216L4fIK+I/OuvzouF 8knk51j7KAGtaDL73tZEz2bVeyXpLBxkFotYgvSjbWpjke6gFRl/EnowuSMKNlB2H/sZtLAMC B39WWm4FtERm4+8aAsA90ECyDK0/d3J2/RYCQpl9dEwc2bs7+5NwHxlab5AVgPfLMrn2OBOw7 0U5VNA2GDmUzSZo1NE0E7auzRjf76m0qICTGUuctVNRoqm+Mh2hPIAJoC+aiZ7hxCEpp9p5+y V7K6KUJC9RCkCyWN1VZ62lUuLeXkeN/6GiHUfNdV9yeVjxwhmEoz7+IYl2tVYfQAye1XAstso FncmH1Nnyul+ArNOo65eqRO/UUEkgH28GWZE9Ngv/ZLlwmJyAiCDFwTrOCp46cNr3kJ3T6sT3 +Vf4EoBVvSR52VI0u7v6lysnyJ+aHDXjv2AMe0wCXYDflSQ== Archived-At: Subject: [Dtls-iot] Secure Time 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, 15 Jul 2015 11:23:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xohxe07uarqlX3QhTCJrHVjluagQcM6MD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen wrote: (9) 14: And also - if you RECOMMEND to sometimes use ServerHello.Random for "secure time" then don't you have to say that that's only to be used after one has verified the server cert/knowledge-of-PSK or something? Otherwise any old fake server could send me a time value then bail on the handshake, and I might set my clock to that. (The bad effect there is not related to certificate revocation btw, but more e.g. DoS for sleepy nodes or application layer nastiness.) I believe that this is what mathewson-no-gmtunixtime said. I will double-check but depending on the outcome of the discussion on issue 31 http://trac.tools.ietf.org/wg/dice/trac/ticket/31 this new issue might not need any additional text... --Xohxe07uarqlX3QhTCJrHVjluagQcM6MD 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 iQEcBAEBCgAGBQJVpkKzAAoJEGhJURNOOiAtzIkH/Rfm9+VRGdaWuG0MU8uXEbp7 QVVuCPiF40/HMblXhrbfR0Olhr9XIglqFl/jE/7YEkiq7fJGhjK3mHSuRphDdIw/ Uy0AvlAtTyUtNpucQ4itKsvD4+r7byyVpN2t+8/IwIHUiBOrPN1vXwHxbyBRJFB8 /yAzLDNvY3JyCnB3kPSiUAx6tCYgSY2hnXdOG8/bEWXe+v6/ddJkyezljqfSeEKD 3bi742dgz8mdTVDs8GFTDqHVu41rZtwlIIs+ktLXY23Cy5KgwZvbPgzX/eNVCvJ8 qLHVGsQeqUz4u8CQC2/PygTkRsTDqL5rU3AcTqSjMZ5qJA4DIccVAV3sFbe09+w= =hFwG -----END PGP SIGNATURE----- --Xohxe07uarqlX3QhTCJrHVjluagQcM6MD-- From nobody Wed Jul 15 04:26: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 22EEE1A86F4 for ; Wed, 15 Jul 2015 04:26:15 -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 eI3kVgltKhSR for ; Wed, 15 Jul 2015 04:26:13 -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 47CA71A88C6 for ; Wed, 15 Jul 2015 04:26:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 17051BE53; Wed, 15 Jul 2015 12:26:12 +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 iq10lEBDqzoI; Wed, 15 Jul 2015 12:26:11 +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 C9310BE50; Wed, 15 Jul 2015 12:26:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436959571; bh=D71e+FSzX9a1/umMmSVXWVdN9ijHmau4XaNX8L5rsKQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jZrIpbfwXGGrfqAJRsZy6oLdQWwOcJ2ou3JDA0iaihzJ0p8IrLX3W4Hl7b48ANQAM BqRimNc/vkZNzud1DTAPMOoxd3bdlSDfQlSFl4Uzu6jWUdMcjMjTeaRMHLbJiNmBFJ 0uhmq5zUqwuVAVvZ1YIbVt3FN0DTR7dyAq1Bm6rQ= Message-ID: <55A64353.2080709@cs.tcd.ie> Date: Wed, 15 Jul 2015 12:26:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Hannes Tschofenig , "dtls-iot@ietf.org" References: <55A640D9.5070005@gmx.net> In-Reply-To: <55A640D9.5070005@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OESrfX2FgVXlabSs7fOO6dtSuW3FPAhA9" Archived-At: Subject: Re: [Dtls-iot] Reference to Heninger Paper 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, 15 Jul 2015 11:26:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OESrfX2FgVXlabSs7fOO6dtSuW3FPAhA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/07/15 12:15, Hannes Tschofenig wrote: > Stephen wrote: >=20 > (7) 14: Doesn't [Heninger] really cause many devices to use one RSA > prime factor? That's not the same as "same keys again and again" and in= > any case you're not recommending RSA keys on challenged nodes here. > Shouldn't you do the analysis of the impact of a dodgy PRNG on > populations of devices that follow these profiles and not something els= e? >=20 >=20 > Heninger did an analysis of the deploy infrastructure of that time and > RSA is in widespread use. Hence, her analysis focuses on the problems > with RSA keys. >=20 > However, her observations are general in the sense that a non-existent > or bad random number generator will lead to output that is predictable > or the same with a number of devices. This is essentially what I write.= >=20 > Copy-and-paste from the text: >=20 > --- > Special care has to > be taken when generating random numbers in embedded systems as many > entropy sources available on desktop operating systems or mobile > devices might be missing, as described in [Heninger]. Consequently,= > if not enough time is given during system start time to fill the > entropy pool then the output might be predictable and repeatable, fo= r > example leading to the same keys generated again and again. It's that last bit that's wrong though. With RSA it was the same first prime being "found" with non-negligible probability. As far as we know all the same-key cases are because the private key was installed. And even with e.g. ECDSA privates of randoms-used-in-signing, if one can predict some but not all bits, one still wins the game I think. So s/same keys/weak keys/ would be ok and the reason this is notable is that I think there are likely developers out there who'd think that they must be fine if the public key values are unique. [Heninger] shows us that's not the case. Even better than s/same keys/weak keys/ would be to explain a bit more about [Heninger] - say a para like the above. Cheers, S. > --- >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --OESrfX2FgVXlabSs7fOO6dtSuW3FPAhA9 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 iQEcBAEBCAAGBQJVpkNTAAoJEC88hzaAX42i9WgH/RXvsgkb6omTGPqS0QZ+pvZL a29A5sCykAVGHUKIP1rISp6HS/M159CIegbyHQD5/vls2aDwQs29V7t8u7OS5Hup zVx8yaMq1lhmS1Qjb3yEDrEVnfta9P9LpJE34JpqoUe2jDZhpzzQan2Rk3bngPt/ ad0v2tTcSctTw4uY1tf8y3foPsJvso/U4xRMfC8UhAsJAAUBnM2vWp9reZEQQPM1 EKmr2eHJUQysPe+kZxTRuCojG7p28TQ6Q+9fo7LzLuo2hUfcMP9fdeLoJkySOTnX 1sU85PmeQCCaQarKGR3FrwU4XWaC2MlOptElK5Gk0EQwUZDqVG44MB6tsucmuCE= =TBy0 -----END PGP SIGNATURE----- --OESrfX2FgVXlabSs7fOO6dtSuW3FPAhA9-- From nobody Wed Jul 15 04:31:58 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 F40F21A893F for ; Wed, 15 Jul 2015 04:31:56 -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 M0WVig7pGelt for ; Wed, 15 Jul 2015 04:31:55 -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 25AD11A8937 for ; Wed, 15 Jul 2015 04:31:55 -0700 (PDT) Received: from [192.168.131.133] ([195.149.223.246]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LxcbX-1YvOVv0s8p-017Gzf; Wed, 15 Jul 2015 13:31:52 +0200 Message-ID: <55A644A2.8060402@gmx.net> Date: Wed, 15 Jul 2015 13:31:46 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xhnRQW9uqSTaKGN65UGtKjXK3PStp0pfa" X-Provags-ID: V03:K0:LkchE5Blg8zY5zM7r8GMNNfSIFwKF0R7yra2Wsy5pe0UgLPgSpW iAqyrtHzU97VgXeVRswoGIlVBI0JtrMI34gLmlwG8rXrkkz2RTOrU5tAtaanEN9UV7B3HQ9 uXH+E3zt+2QZTob4OadBNskolrAsvDtqvIAMkhLft83EzTkWJgWXR2Ec818S4uiafE/OjLg QAUZzINNOpvPQqlyJIAHg== X-UI-Out-Filterresults: notjunk:1;V01:K0:mVGl+2dfdJI=:g65hmEhPkHd1SwEje+cStn ePCOG/oSNtqX4hRPs2dE4S+hWHAihydSD7S7zg99iJW92RFkcN+spiZEWPSMCVVu++YGhM4PH d+zdc/BiBNHsdFwmpN3eXQuiRSz8M+UCRvVn6THJaRfapfPi7UpX65uTT+b8MpEkWouzMbdMs sYn+2vx+wW/2ZDOCeGUplYR9KrWs3Qo6UVIxYEoSOKtCQT8IfD2bVpvRGASJN/EU300xhotEM SkUXxyfIO2x7v3EMyU6CHTgTJxpmiqkFS67cvD2FL2J/9D5c9G9wXQC6ZmFNa1sRLoe0rm6Ih w0grGKIT5/foe/okFwn2n2xTWxOspG3vFcD3yAq5RcAtUSEnQmNK28rYetF35VvAn/NcjQz07 1VWZSydV8Y9aabSswF28n4W+8R4gYWJt1IphvbTv3mAFL9XPcJUsZcUL7RIyOL/yIZNmSDxXF NZYUYqACKiBvBbMpZq44Q/2/x7vg2FbFEJ5vANWrlBQypeVVYWOcU85suP+7B1HjNdUmaCuaD 4nxa90KAMDbL3K23saGl4Hzwc0mPMHzdtgviFWcC+zpewfeeP+a2HqCLj0AgycnwY7ONa9tQQ vEQVlTiyav1kxypKWrNx6aKUdn+VzX8ebDrcZc7cT5EEQW4iEJh97aohW0FKb+ab/f2ZxE637 p+xR8T/7ZKA6GIfPPSv/wtLu4VZDlYME9b6wM14UJfv1WCg== Archived-At: Subject: [Dtls-iot] Hardware-based Random Number Generator 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, 15 Jul 2015 11:31:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xhnRQW9uqSTaKGN65UGtKjXK3PStp0pfa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen wrote: (10) 14: I want to check that the WG are really ok with the "MUST" for h/w "quality" RNGs. I really like the idea, but it's very odd for the IETF to have such a MUST touching on the style of implementation. (Say if my entire implementation of TLS is in some kind of VM? Then I couldn't meet this ever.) I think we have to s/MUST/weasel-words/ there tbh, sadly - it's just not our job to mandate implementation styles. The following para though does the job nicely, so maybe s/MUST/ought to/ is enough of a change. In response to a similar comment from Russ I had softened the language already. Here is the remark that Russ had: http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00273.html I am, however, wondering whether we do ourselves a favour if we don't state what the requirements are. The example you have mentioned is also a bit artifical since IoT devices don't run in a virtual machine and even virtual machines rely on hardware features from the underlying host operating system. I hope someone in the group can share their views. --xhnRQW9uqSTaKGN65UGtKjXK3PStp0pfa 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 iQEcBAEBCgAGBQJVpkSjAAoJEGhJURNOOiAtVPIH/1UzTYxDuBR74yyZW1sS+D+9 ZxoDNXRIu2xhBccSgjCVzawzm05fg9isCf6Y9+KA34LuvJSov0ut7wB0VzQB1ZLG Do7s2Jrx0a9zzVneOWKDM9VNYWN/iydaMUp/6MfplVluCYl9k9aAzg5WViCZS+38 SrphQqEfiPHE8xruXVm9nQY96b1dzjS2xDOrKBi+yYyMNvkhlK4j66X0hmUFaYiz nVi6tCuZFXFCZzaxaqsSpTqSkDtWfaLUsDWpved0+RWaopbUUiO+QS+FOBCwYSDN trXox6VxI6moJIuAbRaNSejaChXYWBSAhGZcLBisZNfuGQVRLCiV8nlHl14GrTA= =cTU0 -----END PGP SIGNATURE----- --xhnRQW9uqSTaKGN65UGtKjXK3PStp0pfa-- From nobody Wed Jul 15 04:35: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 5ED9B1A894F for ; Wed, 15 Jul 2015 04:35:20 -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 ebZc7l28FuUn for ; Wed, 15 Jul 2015 04:35:19 -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 F10751A894A for ; Wed, 15 Jul 2015 04:35:18 -0700 (PDT) Received: from [192.168.131.133] ([195.149.223.246]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MFcg9-1ZA9tG3W7R-00EhdF; Wed, 15 Jul 2015 13:35:16 +0200 Message-ID: <55A6456E.4020806@gmx.net> Date: Wed, 15 Jul 2015 13:35:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="858DuN7JPiSuLvG46GSh1XULm6SpLhke2" X-Provags-ID: V03:K0:VX0FUjYcAmQPVl3ZzOHP4KZNNn3wNtcZOx1f/owf6DbaplESCh8 ImHnAuivgCFIfa4y5uPxISgXkFb5yW26JvxbPw/qB+xethNUdK2T+stz9IiB7zWQlwbh9i+ pfWH/tUi4rmTorw3YoZqjMmVJPXfvYJwK/L5qKPhRC8MDCpSrakTrnLHE/GITCro+pkj0fv FQIdzCqugRG8klVR1F2bg== X-UI-Out-Filterresults: notjunk:1;V01:K0:wAFRVI43dys=:4+qnm32xyR66AyObICFXzC dg1Slq3C7rhZtN/CBte9uC9+MeGykObs1yNJuF2y4S63h+Xn7UEONicszMV4ruR2Eb11NxYG+ c3jGF7iwtWJUCxb0FQALB9NT4aiBfQfjShXooIRFAaDGQGzgDhj+yXGAtLfRClC73ROYrzb10 Nu3UlHENHYRPG7N6yfIHKRyHMO1hxlpixYlat3d5n/jZXp/w9p5heZK6fdKMryx6hBDWhFxfC eJK58sbH+m5UYXjVI9tSuQjXzrxpU/xQuuu87ZK9IJgZ/BjQN0QhXt0YW8DWxkfXZozMwSZQy QgTUwZ9JyRhqM7I7DDd8ZnYoySlIQnzFpxwOBqUiMypmNgNsPM4ubwe0OeOrFtvU5zij1IiHY AJD/IrYwhXqerTcyHt5gbY5p3wGEH2ku6be1l7IlIgaB/7Gv59xyXjqzguzyAsOjCnk9l/64Q lHF/K0q+S9b7xLziJt2gwEP71HhKkbg2ObvB6w2nVBv60eA8/4zdYAFUhM3xBjcYM6kQzQHtz dS8/SiZpKKy+0sUyO8ge6ejbvIzUF8ALdy7mQCAXsIF6YbY2Yqc/84TdCNXwBxO42Wh2w3YRM r3289+el4THJ66Ukl3+IfJpn/9EFQWtYA1AmeRa53sj09a8+x+d+F980cbGdoqv1qNX1cIa2H FdYGW4DMY35/HKV25IWNvTlciZ0dLzN2fyAsbLcq7fs0sug== Archived-At: Subject: [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: Wed, 15 Jul 2015 11:35:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --858DuN7JPiSuLvG46GSh1XULm6SpLhke2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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? --858DuN7JPiSuLvG46GSh1XULm6SpLhke2 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 iQEcBAEBCgAGBQJVpkVuAAoJEGhJURNOOiAtaHMH/j0EmAMcmw5XIKhJb6YscowR eo7xUAjAUAUpEHgGRrFTHmj4N2DRu0QVAiOLiESwtSzMI+BPl8sBwc8jijokhr+1 0tL0BIK9u05mH0cAT0G8gDAI40auJjL59emjYDsO69tDqDqd8pgSTer7q1QbOqM7 vQE99baskQFgbwM3yDcKsPL8tgC9qx2CoYexQ9yJGl9c6K/j03fn6Za2dE6GL9Wg S8MJqcciOnNELUjFn7Tne+pjj38AfRAKvlFT0klyPfhc3QbQrK+vGZKxIwqEDgcv AY4Of2zcZj+nNmx+irAW2gQ576nShehRLPNGeh76fCCBK68m9+Zg49C6aR9rYuE= =NllA -----END PGP SIGNATURE----- --858DuN7JPiSuLvG46GSh1XULm6SpLhke2-- From nobody Wed Jul 15 04:46:35 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 414FC1A8994 for ; Wed, 15 Jul 2015 04:46:33 -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 bAU0Ze26FXvI for ; Wed, 15 Jul 2015 04:46:31 -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 5EEC71A8992 for ; Wed, 15 Jul 2015 04:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t6FBkNBb021051; Wed, 15 Jul 2015 13:46:23 +0200 (CEST) Received: from alma.local (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (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 3mWcPC4XxhzD2gB; Wed, 15 Jul 2015 13:46:23 +0200 (CEST) Message-ID: <55A6480E.5030405@tzi.org> Date: Wed, 15 Jul 2015 13:46:22 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Hannes Tschofenig References: <55A6420E.7040703@gmx.net> In-Reply-To: <55A6420E.7040703@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "dtls-iot@ietf.org" , Stephen Farrell Subject: Re: [Dtls-iot] Reference to mathewson-no-gmtunixtime 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, 15 Jul 2015 11:46:33 -0000 Hannes Tschofenig wrote: > a) Remove the reference to mathewson-no-gmtunixtime and point out that > somewhere a secure time source needs to be made available. > > b) Copy the relevant text from mathewson-no-gmtunixtime into this > document (with appropriate attribution). mathewson-no-gmtunixtime cites > a different motivation for doing what he suggests, which I believe is > less applicable to our scenario. > > c) Work with Mathewson on mathewson-no-gmtunixtime to get it finished. > The profile document would be blocked till that time. > > > If you ask me for a preference then I would probably go for (b). I am > not sure it is, however, in the mandate of the working group to define > TLS-specific functionality. Hmm, profiling this specific field in a way that makes sense for a constrained implementation is well in the purview of the WG. Also, 5246 says: gmt_unix_time The current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, UTC, ignoring leap seconds) according to the sender's internal clock. Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements. Note that, for historical reasons, the data element is named using GMT, the predecessor of the current worldwide time base, UTC. "Clocks are not required..." "higher-level or application protocols may define..." The license to fix this in a profile is right there. (b) is the right way to handle this. ✅ (On a technical level, it seems the intention was to have a source of entropy that also has a good chance to be unique over time. No idea whether this sentiment should be picked up here.) Grüße, Carsten From nobody Wed Jul 15 11:17: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 75E321A90BC for ; Wed, 15 Jul 2015 11:17:51 -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, 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 5dmI6wsp47TN for ; Wed, 15 Jul 2015 11:17:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D501AD061 for ; Wed, 15 Jul 2015 11:17:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05D97E1AF for ; Wed, 15 Jul 2015 14:34:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 04C5563AEC; Wed, 15 Jul 2015 14:17:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E270B63AD9 for ; Wed, 15 Jul 2015 14:17:48 -0400 (EDT) From: Michael Richardson To: "dtls-iot\@ietf.org" In-Reply-To: <55A63EEF.7010608@gmx.net> References: <55A63EEF.7010608@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: 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, 15 Jul 2015 18:17:51 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig quoted (I think) Stephen Farrel as saying: > (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? Hanness> https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-01 Reading this document.... I think that is indeed a must have document. Let's take this out of the IoT space for a moment. Ever turned on a Dell/HP/IBM/Supermicro server that has an "Integrated Lights Out"/iDrac/ServiceProcessor/IPMI interface? Basically this is a small embedded system on the motherboard that speaks http(s), and lets' you manage the server remotely. There are is also APIs into it, and you can do things like install the machine, reboot it, etc. Such systems could easily come with a built-in "Manufacturer Installed Certificate" (aka "MIC", which is sadly, a really confusing TLA), except that the machine will almost always be addressed by IP address, which will either be SLAAC or RFC1918, and will seldom ever have a name ever, and certainly won't have a name when first installed. I see section 3.2.3 would let one have a SubjectAltName that looks like: eui-64+01-23-45-67-89-ab-cd-ef or, I guess equally: eui-48+00-28-21-a7-5e-27 if my browser location tab were to say https://[somemagicsyntax/eui-48+00-28-21-a7-5e-27] then we could dispense with a bunch of inappropriate security warnings. Your document would help very much. -- 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) iQEVAwUBVaajzICLcPvd0N1lAQLGAwgAu4PpeA0Mm79DsdHgRN4vIQuwYFvyjeG7 A4Ed1mH6jqKlZb0mcQm3KsCUzFsnQwU885c8HcIvR19RBKt+RcQUs+iua8+gmGuY GBZU/qENGqgbOgzPF7fO5nVtCAH8dU5GW4gBaPZofJG+q8x22B1SAbHJMTD5li1x HcdDMWENYLaRPoLJFIm94rih9p5TPiE451smNsrkJNmthr/wDNgFCMu2heWzpKvi CScc5M4oLTGhjLii/Q+DGqpcz2vWfPqCBt5jP2ltp3T9sAZs9fj81ekzP/fLvxbK AyV1RYPvxOgsLt7leHEQwSl9ECcbt2N9q0ZWujyj+GglljKS5UF+tQ== =fvdq -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 05:16: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 8C24D1A1A54 for ; Tue, 21 Jul 2015 05:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 zgKQ7ANzeGWm for ; Tue, 21 Jul 2015 05:16:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 CFE361A1A4D for ; Tue, 21 Jul 2015 05:16:18 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1CBFF7285B2F5; Tue, 21 Jul 2015 12:16:15 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6LCGEmR028124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 14:16:16 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.234]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 14:16:15 +0200 From: "FOSSATI, Thomas (Thomas)" To: Stephen Farrell , Hannes Tschofenig , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] IP Addresses in Certificates Thread-Index: AQHQvu6lTNaooH6PIU+dO60aWHwEGZ3cQQkAgAmfKgA= Date: Tue, 21 Jul 2015 12:16:14 +0000 Message-ID: References: <55A63EEF.7010608@gmx.net> <55A641EC.4030203@cs.tcd.ie> In-Reply-To: <55A641EC.4030203@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 21 Jul 2015 12:16:20 -0000 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: >>=20 >> (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 Jul 21 05:32: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 1B2DA1A1AF0 for ; Tue, 21 Jul 2015 05:32:15 -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 Qj1hOf5-QHQM for ; Tue, 21 Jul 2015 05:32:13 -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 73F8A1A1AB3 for ; Tue, 21 Jul 2015 05:32:13 -0700 (PDT) Received: from [192.168.10.134] ([62.168.35.67]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ltqmn-1YqTgk3PZV-011ABd for ; Tue, 21 Jul 2015 14:32:11 +0200 Message-ID: <55AE3BCA.8040202@gmx.net> Date: Tue, 21 Jul 2015 14:32:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" References: <55AE3BA1.7080804@gmx.net> In-Reply-To: <55AE3BA1.7080804@gmx.net> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <55AE3BA1.7080804@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UcWMX9UjhfnX53TtwnHLqEceQOJHK09uq" X-Provags-ID: V03:K0:oCSXesNv0vXmVF/FlMlTmayKMCOo7AlTflUHdR1Ehnl0cOuXA1/ pMfERz9AiFYc0nMwYHLmu3SmQMdr0NOLCvbp7qcVxYKSluIQttMTGdOma+KQdFFhslad3Vr FsUoOY5EedHWkV4L8BrdyHdduUHJGwW8E56EJhD/9NSQycGLf/VdMjfpipKFkO4ksRpKhuN 7HSf8YoSCfIHYx5UVwJbg== X-UI-Out-Filterresults: notjunk:1;V01:K0:flxyD/SILd4=:Bz8LwhWqKI5+aKPHn2wSXJ ZiFDPgz4zuevYkLLzSF2Adeq82dwuw0DFGtuTVhtdOO0l5N48jWKhbJWSOVDzM5NjI4KYWe3/ Q29ZMStJ++w19ARxruv/o/TnDSAhVpbL5wD4K5maoQ/QhfZP5U4S+AgIHYBoKpJQBx+u+BmpE qn0XhbAxld8xcvwQMoF1rhNq8sAu+kg6HACqhmiMA7MRqt45wX16lC/kb5hXddxdb5Lqqwevi a7N+6YoSwFQhUqTAdK2PO7doC3fJWs7hmlwsPNHgkaj87Y0XP+fUXmuySXhHeFD92/mt11uYc IG2y/Rgh3WpesOf1UsqlwqwaErm2BlxPuKIz8Rzu6DDUWo3363TPgG8QxATrI50Yf8gsraJWf G0seCDecaIa8VjEdo+P72gZETDyEB+g/QEri5YSRE47hCf3yOCBwcarXmCdN6f+IF0nEiZlwn ItT0GfgiTd7i93rSAjWchC+ltfU91Ry+urKuH06Mpv//igfCnjl6E8iqCTKur3GI8sXwr9nCI e02r2kxfWvLy0ltpHsvSzBCOVKF1AB/h8RauOsFLxVcHpqiSebIq6CtrrPsKu9Oi67/SLjKRU Pj/V06qFd4ZpC9yWQ67Jt2jsBEnJLWCZH0jicB7hHn1Mom78CV90dZnyJnXeHDn8ivJtOy6PI VelH3frOc//7wKRi1aJq+E8+RBLayRofk0Kkc8CwTzLgnx6WmDMq4UICtBs7pYi1nSVM= Archived-At: Subject: [Dtls-iot] Interoperable Software Update Mechanism 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, 21 Jul 2015 12:32:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UcWMX9UjhfnX53TtwnHLqEceQOJHK09uq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stephen wrote: (3) 6.3: How can you have a MUST for s/w update when there is no well-defined interoperable way to do that. I think s/MUST/need to/ would be right here. (I'd love to see us define the IETF bits of a s/w update mechanism that could be referenced via such a MUST but we don't have that today so it's a bogus MUST as written.) You are right. The use of RFC 2119 language was incorrect. I changed the sentence and removed the must. Since I changed the text in Section 6 already based of one of your other comments. Ciao Hannes --UcWMX9UjhfnX53TtwnHLqEceQOJHK09uq 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 iQEcBAEBCgAGBQJVrjvKAAoJEGhJURNOOiAtLXsH+wXZrM64z0Hhql3u6ews1dqG ZM4PmYrKxNRC8+AzbJplgcULw5FfJ4RcC8wbQDQGbzFZMb6N7VI9aWxDa7YI5/4q m+qJxDCG7/cQY5FqBaw97QM7xqoFY1T3MXfFLyYTyO+iI48R1Fg7jlu6PIDbCJR7 x7EYUmc3eMhNt7OVLXBkenvAD4GE6bLOeiQ4yXAYMyzy4zdl5AnPviRLdYH+Yet7 DrPrgN/aS8lDJt9XklLtspDyK0V8DB0nMPJel3LxxF58bO6IoM2RwKu7gy3QM2mX UA4F6eXovndb9CGscjYiLz+j/oQCJpL8K6qB7Fe2e3LXeSJ71+UNDNtb5lahRUU= =1M2u -----END PGP SIGNATURE----- --UcWMX9UjhfnX53TtwnHLqEceQOJHK09uq-- From nobody Tue Jul 21 05:41:26 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 D10AC1A1B57 for ; Tue, 21 Jul 2015 05:41:24 -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 OYOecm576vOs for ; Tue, 21 Jul 2015 05:41:20 -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 6F00D1A1B88 for ; Tue, 21 Jul 2015 05:41:20 -0700 (PDT) Received: from [192.168.10.134] ([31.133.152.120]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MV5tl-1ZRhqL0Jbx-00YPaJ; Tue, 21 Jul 2015 14:41:16 +0200 Message-ID: <55AE3DE9.6070700@gmx.net> Date: Tue, 21 Jul 2015 14:41:13 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , "dtls-iot@ietf.org" References: <55A640D9.5070005@gmx.net> <55A64353.2080709@cs.tcd.ie> In-Reply-To: <55A64353.2080709@cs.tcd.ie> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FixN7nKg6QCNe0vaXXKFUqgticdLEDJQ8" X-Provags-ID: V03:K0:Bu/XIpg9GzQSpOiubG48fqMMN6qf7OZwCfbIk5Wh7PGf/DvCXPa l22d7WE9jBCWvETswbYNewlS6EoBpgklAXwQTQAD5Fq6QjAxeEYHiQQJ9N/quoPPru/KlGj htRTCNKtWKNsz7tSTuCjnVOdBUBy41pby7h+YiZrGsZKPcG2DEBMvU7bJk7+t946kyNTuwV i6aVRsd6DW54OWjYkKGHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Bshkz0L47WQ=:nTbKm/vuCbWXukOjugbjou rT82jEV5Z+RuuAIwG10xMfFWNDKzuRwtdKvDxr9vtRXBcrrUZojctvW5/3t5u1nguI8x/RPGg ECKnh2xIdOjM/TEywJx9cIoSwyQyvupZABExlaZD57tRfD+EpDns+Q0eVu0LcMKjNwzVU3FnA Di6VFjNAC4+lbGEy2Aa5UHmRoIrAteeRTQG6Gx6dW4CnGTnKfDmAyDoLp0HNhws29yBWmArw9 DpxmEEespkfdmQoFYNwscLyxaOH7X3xDwYsXf+rnfD9+h3YQKaNqDYj2vvXOLpY+9bU/31yQp O0htr4NTi4eK6TBrwJitN326doZXIt2nlkS4L5FIjz+NJfMtGTwgDZJkshtua2Ex0VBffIZLy WTBjbgu3Jzs0jKexivo7bb6stVKkuh75QsDVaj9Nnt9EXxQlCXSIe9uhtbPG7hm1azeQvBiMH 3gYQ1YHT6fmBuKX8jwQeOpZp9oaR4cDuz+rw6cVqyAk1mcdoyb8TPsHx+/VTfjcj3jtZpGCc5 XYWQrFrY7X9S574PdRFPKWi6vHZrRbCAwfHQP3ETFeBdNWw1oeWjBjSQjktI7rbgIok5IrcKV gw00lh8u3MLLCyC1u83ZHSU+inwsU1X2cB4sEI7S7UlHWDOA+lBrybVM33opy2xi2S/rr7RyX LzGZvjPgwUxs/9tcdH0ASMZxtBo7B12nA/Q2XI/RapR1O6w== Archived-At: Subject: Re: [Dtls-iot] Reference to Heninger Paper 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, 21 Jul 2015 12:41:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FixN7nKg6QCNe0vaXXKFUqgticdLEDJQ8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen, I discussed the issue with Thomas, my co-author, and we know understand the misunderstanding. We thought it would be easier to remove the reference to the Heninger paper. Here is the new text: --------------------------------- 14. Random Number Generation The TLS/DTLS protocol requires random numbers to be available during the protocol run. For example, during the ClientHello and the ServerHello exchange the client and the server exchange random numbers. Also, the use of the Diffie-Hellman exchange requires random numbers during the key pair generation. It is important to note that sources contributing to the randomness pool on laptops, or desktop PCs are not available on many IoT device, such as mouse movement, timing of keystrokes, air turbulence on the movement of hard drive heads, etc. Other sources have to be found or dedicated hardware has to be added. Lacking sources of randomness in an embedded system may lead to the same keys generated again and again. --------------------------------- Ciao Hannes On 07/15/2015 01:26 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 15/07/15 12:15, Hannes Tschofenig wrote: >> Stephen wrote: >> >> (7) 14: Doesn't [Heninger] really cause many devices to use one RSA >> prime factor? That's not the same as "same keys again and again" and i= n >> any case you're not recommending RSA keys on challenged nodes here. >> Shouldn't you do the analysis of the impact of a dodgy PRNG on >> populations of devices that follow these profiles and not something el= se? >> >> >> Heninger did an analysis of the deploy infrastructure of that time and= >> RSA is in widespread use. Hence, her analysis focuses on the problems >> with RSA keys. >> >> However, her observations are general in the sense that a non-existent= >> or bad random number generator will lead to output that is predictable= >> or the same with a number of devices. This is essentially what I write= =2E >> >> Copy-and-paste from the text: >> >> --- >> Special care has to >> be taken when generating random numbers in embedded systems as many= >> entropy sources available on desktop operating systems or mobile >> devices might be missing, as described in [Heninger]. Consequently= , >> if not enough time is given during system start time to fill the >> entropy pool then the output might be predictable and repeatable, f= or >> example leading to the same keys generated again and again. >=20 > It's that last bit that's wrong though. With RSA it was the same first > prime being "found" with non-negligible probability. As far as we know > all the same-key cases are because the private key was installed. And > even with e.g. ECDSA privates of randoms-used-in-signing, if one can > predict some but not all bits, one still wins the game I think. >=20 > So s/same keys/weak keys/ would be ok and the reason this is notable > is that I think there are likely developers out there who'd think that > they must be fine if the public key values are unique. [Heninger] > shows us that's not the case. >=20 > Even better than s/same keys/weak keys/ would be to explain a bit > more about [Heninger] - say a para like the above. >=20 > Cheers, > S. >=20 >=20 >=20 >> --- >> >> >> >> _______________________________________________ >> 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 --FixN7nKg6QCNe0vaXXKFUqgticdLEDJQ8 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 iQEcBAEBCgAGBQJVrj3pAAoJEGhJURNOOiAtKxkH/R1a3YBtLBWpwwXkfNLWLwrs MvCzNdq+4/9lFZgwGB5KWba13fdIImXcRVmUDuTrvt7rso2xOQE6s4SOWah24InG liVgiC2McJutQbU9+OjTrsF5uqSIrf9kiY/CTfRF7nIVDsEESgsgAHOxhwjL7bxp aSBm9cYlvEXJ3MyNmbq3TNg4rvzSA+c+RexOXjUKgTZxuhRHrjehry3rqaWWWOsp P+lV4+Atk5toaqD5ETgerNnVT0hXkr7rsw+lnzXdZMrUNbdRJNrgI2b8qHsag6Lq +X43+OtqnbGqBagWG1ArJrgZq28X+QO62LYojoBUVqY5lR7ujaB61KvGAdCkVHQ= =/clU -----END PGP SIGNATURE----- --FixN7nKg6QCNe0vaXXKFUqgticdLEDJQ8-- From nobody Tue Jul 21 05:54:07 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 AEE741A6F01 for ; Tue, 21 Jul 2015 05:54: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 4hMm7LKLGBk7 for ; Tue, 21 Jul 2015 05:54: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 6B0EA1A6F13 for ; Tue, 21 Jul 2015 05:53:29 -0700 (PDT) Received: from [192.168.10.134] ([31.133.152.120]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lusmr-1YrVor0lH7-0108dk; Tue, 21 Jul 2015 14:53:24 +0200 Message-ID: <55AE40C1.1060005@gmx.net> Date: Tue, 21 Jul 2015 14:53:21 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" , Stephen Farrell References: <55A644A2.8060402@gmx.net> In-Reply-To: <55A644A2.8060402@gmx.net> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eafbR6OxHd5DfJE2wjouQBBqkHov2u8Fg" X-Provags-ID: V03:K0:7U6jkCeu4BPmGAJMSBvGO8+rS55zhpqanjFXWW+Ysg2D9/w6EhY kfWsOyU2mhd6hX/VTKN3gckCysQT2ZUegl6u49MnekwA8vMSog0st9TNuArxgaAEz/eM31S EkoXDOeAMzlRsj3xZZm+qV28taUE5FVGyO7Mzp04J4ob3cw6d9P53MU9pywfrRC95xJ9USk /CzR/s4f4eGF5NKh7R1RQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:tjIQAPiLYGo=:PBVNqESF8rwbU5Hc59jbGs xcBhOTfMvkXxTwUdxGrcsGGeNt9AkKAqAHO3a/XcdkV08xMl3lc2i2SqwF1fXQmZcHovEQ0Gy mB6TFTEQevj4oZ/NnSmD+KTTn3djA4wdRGrKtQ7C31TWfLY22dbqwwQI9RHEykF/Gcj+ody2E xrcZdHAViiqWcu2jYwTCEXYpt8skBCc0WJnTfnARMrrMf5d3hW2f0PnEMLHAH/3wc17Ki/91X phCaLGtCUOwz92udsNQck3NI8ek/NFxxhNPkUW4uvuoCNiVFA+l5DATVLmtCj0gcD5f2iVKHy ZiZYF2Mr0VS5YiIm7eT125O0c3WLTH5EGoO/xpCBGo/oI32h4GdFt888V5PqMEsfRWCigHRn+ sOgsILXlYA2uOg6amTX+CTbgnmQGOiMQ/POgPsnmaGSXeT+94ZVYog23Tnzh9g0fMdpDJVK+7 nLarL6bJUtGJV3bBuuQt3ODdKqL50Z25OBYd8c/BjFYKmP92Ev8uwUIk7vjR7sB1NI5k4HoZH qD2tO/AdsruUw0HbVbghlCiIEBcsuzqUZuW2XYCbqFAkrYnBV1xx8xiTgsaXQ3d/TU5scAMIc sxnDLMdTXHSSsd75mVv8y+IBmnvqU9RbQZzvq1MGvTiEPiPQcD2Xfjde+vSJ2z0huCMrcIho5 PQvijtBU0GVoJLiC1ijBLxW7UKbE63yToJ5LXVIVz/ReUrQ== Archived-At: Subject: Re: [Dtls-iot] Hardware-based Random Number Generator 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, 21 Jul 2015 12:54:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eafbR6OxHd5DfJE2wjouQBBqkHov2u8Fg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I discussed this issue with my co-worker Thomas and here is the proposed text change to address your issue: ------------------------ IoT devices using TLS/DTLS must offer ways to generate quality random numbers. There are various implementation choices for integrating a hardware-based random number generator into a product: an implementation inside the microcontroller itself is one option but also dedicated crypto-chips are reasonable choices. The best choice will depend on various factors outside the scope of this document. Guidelines and requirements for random number generation can be found in RFC 4086 [RFC4086] and in the NIST Special Publication 800-90a [SP800-90A]. ------------------------ Ciao Hannes On 07/15/2015 01:31 PM, Hannes Tschofenig wrote: > Stephen wrote: >=20 > (10) 14: I want to check that the WG are really ok with the "MUST" for > h/w "quality" RNGs. I really like the idea, but it's very odd for the > IETF to have such a MUST touching on the style of implementation. (Say= > if my entire implementation of TLS is in some kind of VM? Then I > couldn't meet this ever.) I think we have to s/MUST/weasel-words/ there= > tbh, sadly - it's just not our job to mandate implementation styles. Th= e > following para though does the job nicely, so maybe s/MUST/ought > to/ is enough of a change. >=20 >=20 > In response to a similar comment from Russ I had softened the language > already. Here is the remark that Russ had: > http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00273.html >=20 > I am, however, wondering whether we do ourselves a favour if we don't > state what the requirements are. >=20 > The example you have mentioned is also a bit artifical since IoT device= s > don't run in a virtual machine and even virtual machines rely on > hardware features from the underlying host operating system. >=20 > I hope someone in the group can share their views. >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --eafbR6OxHd5DfJE2wjouQBBqkHov2u8Fg 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 iQEcBAEBCgAGBQJVrkDBAAoJEGhJURNOOiAtgVQH/1uHKazO+d+Yiph2p34NX165 YUdsE20yFRIp/WNIJRGZBeUyLVm1y8+xgV6UqNT21tR34w7CL+9c2YzFXAvn39er 0Nozk/NuKMiJAj4C1Q7XTNBIiIRNJCwzA75Adqn1/3mdG/vJfkPYAW1cCALlSuIM /czf2PTy3YPSQd75CSEMmg6UWLym9rr0paKrpaNkuQViGeAgn9+U2sW3eINpXWHJ 3pbtF+rPdPR61IrGx3tNmhTZwxB4tX7MNJEtkTabrtpOljNXosUXFgefsBCYiIt2 ObZpCw6K4z/4gwhS9QjMmYJm4wlwOy9FQDMcfVcABUqiDdhyi8Bu3RuPtxzuM5k= =4Hxl -----END PGP SIGNATURE----- --eafbR6OxHd5DfJE2wjouQBBqkHov2u8Fg-- From nobody Tue Jul 21 05:57: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 82A371A8768 for ; Tue, 21 Jul 2015 05:57:14 -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 FuFVDWyIXMHA for ; Tue, 21 Jul 2015 05:57:09 -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 A279B1A9043 for ; Tue, 21 Jul 2015 05:57:08 -0700 (PDT) Received: from [192.168.10.134] ([31.133.152.120]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MV5tl-1ZRhbC28xZ-00YPvO; Tue, 21 Jul 2015 14:57:00 +0200 Message-ID: <55AE4199.9050104@gmx.net> Date: Tue, 21 Jul 2015 14:56:57 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Carsten Bormann References: <55A6420E.7040703@gmx.net> <55A6480E.5030405@tzi.org> In-Reply-To: <55A6480E.5030405@tzi.org> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Umkl4LGHBmnURiijcVpXkES7V1EwqUjdD" X-Provags-ID: V03:K0:AHQ4LhgfUGmnKNTxQqJR4ErYUBtAR63l82FZypCvm5IpOTafHmi BZhKKNBkUibRT9TTn21lzONhOHKtFHm1smbpaGy+PdpLiAuM4ADyGHEBrx9psKTNMy329n5 Hv496inSzV/x/JK0Ct7Q7DOEhpPJPml+234fW7qLWocXauLv9wzKGtlUVKHojnfEvVIdAHx DJvkY/Tns7v6Y5PGpAZ6g== X-UI-Out-Filterresults: notjunk:1;V01:K0:gGzXiRFqcgI=:a8cxPmkn43i7ykj8+A7o/I klBrRgx31hVr9ayx2GWckjpYYD/SzetqvvBXhJfxKSvGrGAAND1rsjbISpmgoeUq/zDOvC0CC lgau/9iwOxpAHeJsoioJu0n7sGcNp6aOq+gDkvCDC3C2HG/47m/y8K0mgafyhPod0ijkOBDiy CWyDCAX+ZGLlCb7sX6vPIA2tjMZbGw5FTvqrc+jHKs4OgP7Vz+2Z3BFfhxzU16Q+lEFGgKWaD qfpRtjsQe65IBDAY8axCGuWOrNhMbmiSK4jNyxxWW1vyuyLtbABJBt6g0INeQeVb599OWFEGa Q0iSqvZezXlO7Y3G+e7XjghUQtF663LYKR153mRzQcWDCGE8RAC8L2Jij6j2tLfJ4ugcCdYhS 4aRGhL0ahiM0fQ3NNEFbg94Exr9cCRDS+/PwZhD+NxjHAQ+2nkXD3GNphdXgNLmDb1DKDAwRP Es3asSqIbv+zSHyA4NVjlJSed4eRg6nxzRYWyYU7DQQ7bMGhOMX3JXdrn8t43qJb9CbvHipQi JqD3Xp8DJHAdS+Zyz65yJ1IptU0HmP9GGn/FaOD2AtbWIHbOhF7wmyq92T4iuHi/yK5cdeZCa MrXIDTZ6ooT6pVqIVWkhKLGqVAcZE9FvICzdQLKGongaMwUTfYR0eyRjo9bj3+bmg1I+WZCGv cqN7X0938ZIAweDNumucOSH3DudL/Rt9AvEwJ2noZezVieg== Archived-At: Cc: "dtls-iot@ietf.org" , Stephen Farrell Subject: Re: [Dtls-iot] Reference to mathewson-no-gmtunixtime 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, 21 Jul 2015 12:57:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Umkl4LGHBmnURiijcVpXkES7V1EwqUjdD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, thanks for sharing your views. Good that you noticed this paragraph that would indeed make it possible to add appropriate text to the draft. I will work on a proposal and share it with the group. Ciao Hannes On 07/15/2015 01:46 PM, Carsten Bormann wrote: > Hannes Tschofenig wrote: >> a) Remove the reference to mathewson-no-gmtunixtime and point out that= >> somewhere a secure time source needs to be made available. >> >> b) Copy the relevant text from mathewson-no-gmtunixtime into this >> document (with appropriate attribution). mathewson-no-gmtunixtime cit= es >> a different motivation for doing what he suggests, which I believe is >> less applicable to our scenario. >> >> c) Work with Mathewson on mathewson-no-gmtunixtime to get it finished= =2E >> The profile document would be blocked till that time. >> >> >> If you ask me for a preference then I would probably go for (b). I am >> not sure it is, however, in the mandate of the working group to define= >> TLS-specific functionality. >=20 > Hmm, profiling this specific field in a way that makes sense for a > constrained implementation is well in the purview of the WG. >=20 > Also, 5246 says: > gmt_unix_time > The current time and date in standard UNIX 32-bit format > (seconds since the midnight starting Jan 1, 1970, UTC, ignorin= g > leap seconds) according to the sender's internal clock. Clock= s > are not required to be set correctly by the basic TLS protocol= ; > higher-level or application protocols may define additional > requirements. Note that, for historical reasons, the data > element is named using GMT, the predecessor of the current > worldwide time base, UTC. >=20 > "Clocks are not required..." > "higher-level or application protocols may define..." >=20 > The license to fix this in a profile is right there. >=20 > (b) is the right way to handle this. =E2=9C=85 >=20 > (On a technical level, it seems the intention was to have a source of > entropy that also has a good chance to be unique over time. No idea > whether this sentiment should be picked up here.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --Umkl4LGHBmnURiijcVpXkES7V1EwqUjdD 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 iQEcBAEBCgAGBQJVrkGZAAoJEGhJURNOOiAtOrwH/Rqph+oChAptoCQBMA84ORBT 66ot+SWwoLpnoq+iDaH+uGPf1VNckKUp/1zF9WW7ZU/UMlr7DaM/M0GcwFlRvbdr SAaFQ4DbYH8G7YgU2pFWqgunnvgm94pTTevhqy6LDWTAH+bTG2mH6NjfBoULWLdP Vy0w2dJbU+p6byj1MlENN3szkcg3jx5w8UkGDAJVVW9iwuKvxQb0RiAucDvkUXYf QsIVjmKUEVkK/FE4ZW1g1HdEitM/slyOyMwQxTH4bzQFFxpUEFaAXYpXEe8oXurK InHgx7odHqurQ+ebMV+Ucy25Rjr9nuQuuIFeQev+APwcGI75uTdPpddoXNcOaGc= =WJgB -----END PGP SIGNATURE----- --Umkl4LGHBmnURiijcVpXkES7V1EwqUjdD-- From nobody Wed Jul 22 03:56:30 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 1DB451AD377 for ; Wed, 22 Jul 2015 03:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-5, 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 mOV1g6QPdwed for ; Wed, 22 Jul 2015 03:56:26 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 A1F821AD34C for ; Wed, 22 Jul 2015 03:56:26 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9D5C1493F8C35 for ; Wed, 22 Jul 2015 10:56:22 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MAuOHH008313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Jul 2015 12:56:24 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.234]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 12:56:24 +0200 From: "FOSSATI, Thomas (Thomas)" To: "dtls-iot@ietf.org" Thread-Topic: [dice] #36 (profile): Appendix C. DTLS Fragmentation -- Not complete? Thread-Index: AQHQvvM7qNqy/FC+HEuHuAMPgU8A3J3nCiEAgABSDoA= Date: Wed, 22 Jul 2015 10:56:24 +0000 Message-ID: References: <064.ce1e64c37b01e8acba5ca0151ecaf87f@tools.ietf.org> <079.43105472bc069b263357cfa0d335eeb8@tools.ietf.org> In-Reply-To: <079.43105472bc069b263357cfa0d335eeb8@tools.ietf.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <76028B764F7ECC40AFD30C43D5946302@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dtls-iot] FW: [dice] #36 (profile): Appendix C. DTLS Fragmentation -- Not complete? 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, 22 Jul 2015 10:56:29 -0000 On 22/07/2015 10:02, "dice issue tracker" wrote: >#36: Appendix C. DTLS Fragmentation -- Not complete? > >Comment (by thomas.fossati@alcatel-lucent.com): > > We had a further round of reviews from Robert and Matthias (thanks!). > > The email exchange, together with the new text, is copied below. > > ---- > > From: on behalf of Robert Cragie > > Reply-To: "robert.cragie@gridmerge.com" > Date: Wednesday, 22 July 2015 00:27 > To: Thomas Fossati > Cc: Thomas Fossati , Kovatsch Matthias > , Hannes Tschofenig > Subject: Re: DICE ticket #36 > > Hi Thomas - looks good! > > Robert > > On 21 Jul 2015 19:44, "FOSSATI, Thomas (Thomas)" lucent.com> wrote: > Hi Robert, thanks very much for the comments. > > I've removed any reference to specific network technologies because > fragment size adjustments and consequent overlaps happen whenever we go > from a bigger to a smaller MTU (e.g. 1500 -> 1280). Here's the new text: > > =3D-=3D-=3D-=3D > > Section 4.2.3 of [RFC6347] advises DTLS implementations to not > produce overlapping fragments. However, it requires receivers to be > able to cope with them. The need for the latter requisite is > explained in Section 4.1.1.1 of [RFC6347]: accurate path MTU (PMTU) > estimation may be traded for shorter handshake completion time. > > In many cases, the cost of handling fragment overlaps has proved to > be unaffordable for constrained implementations, particularly because > of the increased complexity in buffer management. > > In order to reduce the likelihood of producing different fragment > sizes and consequent overlaps within the same handshake, this > document RECOMMENDs: > > o clients (handshake initiators) to use reliable PMTU information for > the intended destination; > > o servers to mirror the fragment size selected by their clients. > > The PMTU information comes either from a "fresh enough" discovery > performed by the client ([RFC1981], [RFC4821]), or from some other > reliable out-of-band channel. > > =3D-=3D-=3D-=3D > > Cheers, t > > From: on behalf of Robert Cragie > > Reply-To: "robert.cragie@gridmerge.com" > Date: Tuesday, 21 July 2015 17:18 > To: Thomas Fossati > Cc: Kovatsch Matthias , Thomas Fossati > , Hannes Tschofenig > Subject: Re: DICE ticket #36 > > A couple of points: > > Point 1: > > "the cost on the constrained implementation in terms of memory (due to >re- > buffering) and latency (due to re-transmission) would be much higher than > the benefit that it would get from a theoretically shorter handshake." > > I presume this means "the cost from assuming an infeasibly large MTU..."? > Maybe this should be made clear. > > Point 2: > > If IEEE 802.15.4 is being used, 6LoWPAN is the only shim available and > fragmentation would occur at the 6LoWPAN shim. This means that the MTU is > effectively 1280. So for that reason, I would probably take out IEEE > 802.15.4. Also, I believe that BT Smart also does its own fragmentation > and reassembly in the L2CAP layer so I presume the same would apply to BT > Smart (although I am not an expert). > > Robert > > > > On 21 July 2015 at 13:56, FOSSATI, Thomas (Thomas) @alcatel-lucent.com> wrote: > On 21/07/2015 14:38, "Kovatsch Matthias" wrote: > >>Good feedback, thanks very much! Just to avoid any ambiguity: PMTU > >> doesn't need to be done before each DTLS handshake. It could be done > >> once and the information cached for as long as it's reasonable. > > > >Yes, that's what I assumed. I was even thinking about adding this > >information to the draft. And since you clarified this here, I now think > >it would be best to also put this reminder into the document :) > > I agree it's worth a further editorial pass :-) > > >> I've slightly re-written the text to match your suggestion: > > > >Sounds good. > > > >Ciao > >Matthias > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-dice- > hannes.tschofenig@gmx.net | profile@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: >Component: profile | Version: > Severity: Waiting for Shepherd | Resolution: > Writeup | > Keywords: | >-------------------------------------+------------------------------------ >- > >Ticket URL: >dice From nobody Wed Jul 22 23:24: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 87C5A1A8771 for ; Wed, 22 Jul 2015 23:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ZF3kbImEOQCM for ; Wed, 22 Jul 2015 23:24:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 09FAA1A879A for ; Wed, 22 Jul 2015 23:24:32 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 597CCF60319BC; Thu, 23 Jul 2015 06:24:29 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6N6OUCZ018196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 08:24:30 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.234]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 08:24:29 +0200 From: "FOSSATI, Thomas (Thomas)" To: Stephen Farrell , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] AD review of draft-ietf-dice-profile-13 Thread-Index: AQHQuAc7gNfJL+A2WUmOuinYGFblJ53osGKA Date: Thu, 23 Jul 2015 06:24:29 +0000 Message-ID: References: <559AA9F8.6080005@cs.tcd.ie> In-Reply-To: <559AA9F8.6080005@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dtls-iot] AD review of draft-ietf-dice-profile-13 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, 23 Jul 2015 06:24:36 -0000 Hi Stephen, On 06/07/2015 17:16, "dtls-iot on behalf of Stephen Farrell" wrote: >(6) 13: sorry I don't get why a 1 second initial timer >is an issue because messages "need longer" (we're not in >a DTN, right:-) I don't think you've justified the 10s >initial value and that might be bad in fact e.g. for >sleepy nodes one might want a much shorter initial >timeout so the node can go back to snoozing. (It could >be that this 10s value was justified on the list, but >I'm not getting it from the text. Or is it appendix A >you're thinking of? If so, that seems overly specialised >for a generic 10s recommendation.) the relevant text is: "[...] these values are too aggressive and lead to spurious failures when messages in flight need longer." which I reckon is a bit too terse. The full story is: * TLS protocol steps can take longer due to the time spent figuring out the crypto bits on the constrained side; * DTLS retransmission, which is per-flight, interacts very badly with low bandwidth networks; so, it's essential that the probability of a spurious rertansmit is minimised. Also, on packet loss, the sending node should not react too aggressively: if lost packets are re-injected too quickly into a temporarily congested WSN, congestion worsens. The 10s is a conservative guess that tries to cater for the worse case (i.e. very constrained endpoints and/or networks that are congested or with high delay variance - e.g. GSM-SMS). Re: sleepy nodes. Even when starting with a 1s timeout, they need to be prepared to stay awake for the maximum wait time which is roughly 1 minute. This is not a MUST, anyway, so sleepy nodes could use a lower value, both for the initial timer and, most importantly, for the threshold. I have this new text in my working copy. (Note I have slightly tweaked the value -- 10 has become 9 -- to get the same max wait you'd get with the usual 1s initial timeout): TLS protocol steps can take longer due to higher processing time on the constrained side. On the other hand, the way DTLS handles retransmission, which is per-flight instead of per-segment, tends to interact poorly with low bandwidth networks. For these reasons, it's essential that the probability of a spurious retransmit is minimized and, on timeout, the sending endpoint does not react too aggressively. The latter is particularly relevant when the WSN is temporarily congested: if lost packets are re-injected too quickly, congestion worsens. An initial timer value of 9 seconds with exponential back off up to no less then 60 seconds is therefore RECOMMENDED. This value is chosen big enough to absorb large latency variance due to either slow computation on constrained endpoints or to intrinsic network characteristics (e.g. GSM-SMS), as well as to produce a low number of retransmission events and relax the pacing between them. Its worst case wait time is the same as using 1s timeout (i.e. 63s), while triggering less then half retransmissions (2 instead of 5). In order to minimise the wake time during DTLS handshake, sleepy nodes might decide to select a lower threshold, and consequently a smaller initial timeout value. If this is the case, the implementation MUST keep into account the considerations about network stability described in this section. How does it sound? Cheers, t From nobody Fri Jul 24 15:33: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 CB57A1A90A7 for ; Fri, 24 Jul 2015 15:33:19 -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 XxEgJ717TYrq for ; Fri, 24 Jul 2015 15:33:18 -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 544631AC3B0 for ; Fri, 24 Jul 2015 15:33:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 18927BE87; Fri, 24 Jul 2015 23:33:16 +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 jXZcknqKo0SI; Fri, 24 Jul 2015 23:33:15 +0100 (IST) Received: from [10.0.2.224] (unknown [62.168.35.66]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0232CBE7B; Fri, 24 Jul 2015 23:33:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437777195; bh=baq3PLHkn96Ozr27uMevzztyIMik8r+OkUBd76tjATk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=eR+KDDu9cCz9oYx0XzYu8meYor8wi5WOolfpwcEr41KQwmTHxRy5pqLPMiXLp80gG XYRs5NacmA4Q0G5ZCdYwqTH/2zBU9uWEAiMGkDN1hTMDTwrLX9pZAzCy2HlV5Bpxdi c4NYnGySfk3jvI06pNChWkI5t2MWGHLDf+zmlAsw= Message-ID: <55B2BD2A.1080209@cs.tcd.ie> Date: Fri, 24 Jul 2015 23:33:14 +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: "FOSSATI, Thomas (Thomas)" , "dtls-iot@ietf.org" References: <559AA9F8.6080005@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dtls-iot] AD review of draft-ietf-dice-profile-13 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, 24 Jul 2015 22:33:20 -0000 On 23/07/15 07:24, FOSSATI, Thomas (Thomas) wrote: > How does it sound? Good enough for me:-) I'd not be surprised if we get feedback on this from transport folks during IETF last call or IESG evaluation but we can deal with that as we get it. Thanks, S. From nobody Fri Jul 31 13: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 488E11ACD2A for ; Fri, 31 Jul 2015 13:03:47 -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 EBCnZL7XEH0x for ; Fri, 31 Jul 2015 13:03:45 -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 94CC71ACD22 for ; Fri, 31 Jul 2015 13:03:45 -0700 (PDT) Received: from [192.168.131.133] ([80.92.122.31]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Meutp-1ZVuic2amv-00OTsy for ; Fri, 31 Jul 2015 22:03:43 +0200 Message-ID: <55BBD487.4060002@gmx.net> Date: Fri, 31 Jul 2015 22:03:19 +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="u5JIqIor4bWhnb25lsc7VVWestBml9v92" X-Provags-ID: V03:K0:xHjELtgcwQ3y0dvQP+Yw4av+2hspEhRrBvvVlnDcFN98cmvREw5 S4oNZRWQP1YUsLm49PuvEXmyLckoY1HhGUxZqWp05R8MF4cL0dxgXdBGEYb0GxW0jf1kxtc uh3ZeRGn9K7dpR+VLINk7cIyf730AnsA+dKpczM09SOqxN25hn4ADxgZa8iCokfTM2j39lJ 9ZbZgeZ2P3L6hel+WEPJQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:bs0IrYRyG0A=:0sH+E7gTF3xnjRHUnMbJMd tKf6fUuq751N6l3XXhBPsJ5c43AST3KdbQRf8lE875tUEPh8QFNgGFIUNSI724my1taGdwkiw OZ8WsDrpRFQRL4FVBxdCxi4VOo7j6h1Wc97exLTwXjvS5uqEbLkNJwQQn0lnR/lb++57FKw6Q RaoftNbZPrVl8T/7mleFXIMKo3nKxsP+usI1hHKSIKBXdWZ7GezdIEmGg1kdxBBWZCBoQyuv+ gPqgcKpKq43WZQp6AZcNqBv30Rs32gDzcxhXOGhSLRX8dUY3OLSCQDSmlZR6t9cwWa1GdVXpr dulZPy8wL7JdG2wOnZ1X1i7EhAW3PGsZPK8uf0bF4VcU3C8dMAPeu/LItvQD6EHpit8N2GefV GI0Dxov4gkWn3paVjOZO8DU88Uqb+oYa8eQoqEu7KxTuP6zbjb7MQ2/dwUTChNvHmLw6eF+ay ucfHfBNnqHHAPiYh2OLgTx0aJyiRQo/ukcRSXrtZkd8kiat731pu29el9KGTAUSqRzl2KmpJ6 o1w5NGHM33vwkS2oGFoqPxeVf+ZpaH24cmgTl851ewHkTjepB99W2Nbf1qvnNOqCLZDFq32Xw /fKCaUgu36vH2/YY4uAXl6MEbX7Rh2wlkSYGRCOKiZc84F2355bBwvj0+4+oenssawBEcv8Wx 7kh//8bZxrAaOr1e1wqN+pG8Qj2N6yhnehH5v8HTV+a7CvQ== Archived-At: Subject: [Dtls-iot] Concluding Issue #24: Replacing TLS_PSK_WITH_AES_128_CCM_8 with TLS_PSK_WITH_AES_128_CCM 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, 31 Jul 2015 20:03:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u5JIqIor4bWhnb25lsc7VVWestBml9v92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Based on the discussion on the IRTF CFRG mailing list, see http://www.ietf.org/mail-archive/web/cfrg/current/msg07138.html, I leave the current recommendation unchanged. I added a note with a reference to Section 6.2: " Note that the shorted authentication tag increases the chance that an adversary with no knowledge of the secret key can present a message with a MAC that will pass the verification procedure. The likelihoods of accepting forged data is explained in Section 5.3.5 of [SP800-107-rev1] and depends on the lengths of the authentication tag and allowed numbers of MAC verifications using a given key. " Ciao Hannes --u5JIqIor4bWhnb25lsc7VVWestBml9v92 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 iQEcBAEBCgAGBQJVu9SHAAoJEGhJURNOOiAt+fQH/2weEisxiSRtibc5hB1+bzp0 N7xTZylYmKSkd8gVcKgvKG4nrDvBbqEjzAUcjwt9MtTkiafrDnZtuCce1AERNzLR OHuPPuOPnTZ3QqK9JxiK6iMkJsN98GGZBKo99F44vIdebPJyKi3sr/pP7rDcVolB ufMF+q0hMGUkxox82j9oNtnSQ47euh63OII2Y4EJ/xZF6FfW/+7M4MWymPxvHdy1 TzXKp5se5h75wV/LeVYkOjWrBV7TM6CMuzfndkaXCjK4PUwk91vPgOICq+ZaoLGL dW1BarOBPUjW78RbwXO/UadYzpEZEdKHfjoWOuKhRyhm5Of3PanhwKt4RcE7JzY= =ssuj -----END PGP SIGNATURE----- --u5JIqIor4bWhnb25lsc7VVWestBml9v92-- From nobody Fri Jul 31 14:15:35 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 C63D81A0095 for ; Fri, 31 Jul 2015 14:15:34 -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 M_CtpYhZkNC4 for ; Fri, 31 Jul 2015 14:15:32 -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 D44851A0041 for ; Fri, 31 Jul 2015 14:15:31 -0700 (PDT) Received: from [192.168.131.133] ([80.92.122.31]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LZiLk-1Yc1Gg0aTM-00lXRs; Fri, 31 Jul 2015 23:15:30 +0200 Message-ID: <55BBE557.3090206@gmx.net> Date: Fri, 31 Jul 2015 23:15: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: "dtls-iot@ietf.org" , Stephen Farrell OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CsKBxrsBFKNsQROJL7JmSDCTe4sFohP97" X-Provags-ID: V03:K0:e7i9DvAaWZ3IQAXmxm7dLQogpAfVEFBm+ly26CLza6Ar7vg+aRt 9TvwBmdMLh0aoDmTBh0yjwDRb+OwnZZVxgsi70+cdHkLtfhQ18HIIffiH8GTEMsj1xIblZ6 Sa142eEgvojR5NiRyMH8jU0E22rdP7ZMx7gUZcBT21p0+K6PSAnt9hVIDXHBDQ2W41ply6C jQYdg1l6nv+Q29dNqzxhw== X-UI-Out-Filterresults: notjunk:1;V01:K0:WbSeEnhSmrA=:+K1HNZ6bnP87/KkRjOaUsn wprx+pLzJn0N4usm5xUAVldPgJ1ZJaF3p+XbmTM2P8+AfoW+8rHZZ5SOvpCxqI78lyYshup3V mItpkzXsexbaOnoyqhCp2sjomGD6QlYwTEIBu41eMTRH/8WDeKWQrUYxH1HbArgP8MYjr5Wxw CYjXstTNq+eG354fnTdco3Hzy7KhXHJrSve5hvBVBWZ5r+QnwliAsHOLCAF44VrCt22AhvbZI Ayk9n0k+XBGDyy02GlQ1QUtpdR60H6KkPoMqRHGQ68sPeb97sWcjWaIdNQPlvLsfuMNf6BlJ+ Y3G2i6CQHcjIKf0NoNEEtTvnUpo9CgEUhbSTVGvxjC6x1Tx69MxdGgr+EGC8g4MN2kFz0+WSb GuDEPrf3v8/2ibPpAOxkg7vgdcKomKYlEk9BbI9YX1omz8fv2E4viE5p4jfSk1TwXqaS745r8 4VZ1BDOTFxQxzUHbLLXNlLhPZOYbhbHaAdz+Eq8iwxtKf5ZFo9IfNlsBYAzxhzDWPEl8CCFOF gZ8bjHsYTeShWfqtvjBrQf8g84LNZU8ED3eCNkB8hatrTI2D2P4LHSRMDIULjg6fVzBF1C3Kq fgUIjbgFQswDV7IphbwPQ7Wdx5k2Ybr7sDXFMF6bYsFTh/G2NPmLxZVvwhkSFP74Jjs1T08Mt Hf8fImUvg8s8lqnvPswB5vYCPTsJgA1jfC7CEBQ3GEPOFGA== Archived-At: Subject: [Dtls-iot] DTLS/TLS IoT Profile Draft Status 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, 31 Jul 2015 21:15:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CsKBxrsBFKNsQROJL7JmSDCTe4sFohP97 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, based on your review we have created a number of tickets in the DICE WG issue tracker, as you can see here: http://trac.tools.ietf.org/wg/dice/trac/report/1 Over the last few weeks we have been trying to resolve these issues and here is the current status. The updated draft can be found at: https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profi= le/draft-ietf-dice-profile-14.txt * Replacing TLS_PSK_WITH_AES_128_CCM_8 with TLS_PSK_WITH_AES_128_CCM http://trac.tools.ietf.org/wg/dice/trac/ticket/24 Recommended Action: Close ticket based on CFRG discussion: http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00643.html * Unique Key Pair per Device http://trac.tools.ietf.org/wg/dice/trac/ticket/25 Recommended Action: Close ticket based on your response: http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00623.html * Interoperable Software Update Mechanism http://trac.tools.ietf.org/wg/dice/trac/ticket/26 Recommended Action: Close ticket based on our changes. * Ed25519 http://trac.tools.ietf.org/wg/dice/trac/ticket/27 Recommended Action: Close ticket based on our changes. * IP Addresses in Certificates http://trac.tools.ietf.org/wg/dice/trac/ticket/28 http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00625.html ### Still open ### * Timer Setting http://trac.tools.ietf.org/wg/dice/trac/ticket/29 Recommended Action: Close ticket based on your response http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00642.html * Reference to Heninger Paper http://trac.tools.ietf.org/wg/dice/trac/ticket/30 Recommended Action: Close ticket based on our changes. * Reference to mathewson-no-gmtunixtime http://trac.tools.ietf.org/wg/dice/trac/ticket/31 http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00628.html ### Still open ### * Secure Time http://trac.tools.ietf.org/wg/dice/trac/ticket/32 http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00629.html ### Still open ### * Hardware-based Random Number Generator http://trac.tools.ietf.org/wg/dice/trac/ticket/33 Recommended Action: Close ticket based on our changes. * RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement? http://trac.tools.ietf.org/wg/dice/trac/ticket/34 http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00632.html http://www.ietf.org/mail-archive/web/cfrg/current/msg07082.html ### Still open ### * Privacy Considerations http://trac.tools.ietf.org/wg/dice/trac/ticket/35 ### Still open ### * Appendix C. DTLS Fragmentation -- Not complete? http://trac.tools.ietf.org/wg/dice/trac/ticket/36 http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00640.html Recommended Action: Close ticket based on our changes. * DTLS Server-Initiated Session Resumption http://trac.tools.ietf.org/wg/dice/trac/ticket/37 Recommended Action: Close ticket based on redrawn figure in Section 4.1.1= =2E2. * Certificate Chain in DTLS/TLS http://trac.tools.ietf.org/wg/dice/trac/ticket/38 Recommended Action: Close ticket based on our changes. To summarize: I believe issues #24-#27, #29, #30, #33 #36, #37, and #38 can be closed. Please confirm whether you are indeed happy with the suggested changes. The following issues are still open: #28, #31, #32, #34, #35 Ciao Hannes --CsKBxrsBFKNsQROJL7JmSDCTe4sFohP97 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 iQEcBAEBCgAGBQJVu+VXAAoJEGhJURNOOiAtMDEH/05i7IZDIVPi1AfH3IwUn7wf joIsRvNZRbpViRDLU784zCoGAASGp+yz0EGEX7LG5zlaBq125yBW6Pu4MIRT8pfY tTPQc+uvHQNOFd9Py2ZFnw593IUqEWb3uukyHR0j0egSVdF5hcualIl7TghMKJIY 6hxbwmJeLVpvp9oI3pPDs2ejY9mBvLWUmKYdW5LF8J4lkiKjHxshmIFCe1jNIEQW GpXloH4buitvBnE39OWcOdFzZMzNwF7V7Be2nJ6KFv011hIhQYvbzfPAx23LO+DF 7YxojTRQmu/7a6YSCjxv0WDXQgj27/xRPRQwMVvHVkXtdIeicKjXW2pNhZrzdWc= =+D9X -----END PGP SIGNATURE----- --CsKBxrsBFKNsQROJL7JmSDCTe4sFohP97-- From nobody Fri Jul 31 14:21: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 A6FD61A036D for ; Fri, 31 Jul 2015 14:21: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 8TuAKVf2Q2BH for ; Fri, 31 Jul 2015 14:21: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 5368A1A01D5 for ; Fri, 31 Jul 2015 14:21:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 401F3BE38; Fri, 31 Jul 2015 22:21:23 +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 q60UPjXRFjb6; Fri, 31 Jul 2015 22:21:22 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.103]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 190C8BDD8; Fri, 31 Jul 2015 22:21:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438377682; bh=D+iym/5Yki5IRy8/KN7zdoBIX03yEkNAQFvwQ7QqqXc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=bdU5P7i1fG4m1Ao0HSK+X3Eu5ucARrTzgbTkqx5fW/wNGN8MXSaTT6a94r2Ba1syD YcAzWOhGKkDrdZo4PjhQqMkkwWJgBEwNM9nxsyHHOmVi+bWkacOJMrSBHnBBkcLqow aPZXLBitsMtrbvtydE10xRHzqIOMzDJwCdZU2kFU= Message-ID: <55BBE6D1.8090009@cs.tcd.ie> Date: Fri, 31 Jul 2015 22:21:21 +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: <55BBE557.3090206@gmx.net> In-Reply-To: <55BBE557.3090206@gmx.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B4P9MH7KQ05R7l3IUw2TJA3BJfMvW5Pn7" Archived-At: Subject: Re: [Dtls-iot] DTLS/TLS IoT Profile Draft Status 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, 31 Jul 2015 21:21:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B4P9MH7KQ05R7l3IUw2TJA3BJfMvW5Pn7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for causing all that work;-) On 31/07/15 22:15, Hannes Tschofenig wrote: >=20 > To summarize: I believe issues #24-#27, #29, #30, #33 #36, #37, and #38= > can be closed. > Please confirm whether you are indeed happy with the suggested changes.= I'll check and confirm this when I get a chance. If you don't hear back by Tuesday (it's a holiday here Monday) please do hassle me. Thanks, S. >=20 > The following issues are still open: #28, #31, #32, #34, #35 --B4P9MH7KQ05R7l3IUw2TJA3BJfMvW5Pn7 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 iQEcBAEBCAAGBQJVu+bRAAoJEC88hzaAX42i/KoH/2pr0GSY9IBsOorypC97AKUN nb4Y9baM4X6+R24WA7Wx1r2JvuzickKgYdrsZ2Ri7JVGbGLuMb9HFVe7TUV0bl1H vCJsAZysq1qPDSFSIpLEniTmBeHcKbJ2m9kjQ3kJShDKkH6TNC9KgrUC5u+aDeqr N+Z4hHNkuwxVmFdO+PkSZ8lkpXGIzX1cDKDP2NqaQBGM7fL0ON4r8MiyKOwLURYb Ew7LsObXjMYckWkSOyWUJJefRbCsg1sEjDdqFx/rMJQbwGgCTsuNlQ37Drwk+xrn ggi/LtxV2u2LoDmRDaGc7zcVCdmVs/HZbaiKPwBCRFBW41vOvFUzWbDEz5dGXvM= =dn0/ -----END PGP SIGNATURE----- --B4P9MH7KQ05R7l3IUw2TJA3BJfMvW5Pn7-- From nobody Fri Jul 31 23:11:46 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 F08B91B2AAC for ; Fri, 31 Jul 2015 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 7yYJZ_RrYEu1 for ; Fri, 31 Jul 2015 23:11:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 5373E1B2AA9 for ; Fri, 31 Jul 2015 23:11:43 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 916EDB8EC7CF1; Sat, 1 Aug 2015 06:11:39 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t716BeS2001195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Aug 2015 08:11:40 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.234]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sat, 1 Aug 2015 08:11:40 +0200 From: "FOSSATI, Thomas (Thomas)" To: Hannes Tschofenig , "dtls-iot@ietf.org" , Stephen Farrell Thread-Topic: [Dtls-iot] DTLS/TLS IoT Profile Draft Status Thread-Index: AQHQy9YRr++9WDWkLEe5MjoXgqF8LJ32mWoA Date: Sat, 1 Aug 2015 06:11:39 +0000 Message-ID: References: <55BBE557.3090206@gmx.net> In-Reply-To: <55BBE557.3090206@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D3C1A8793AD4544B0CBB8C6EE91980F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dtls-iot] DTLS/TLS IoT Profile Draft Status X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 06:11:45 -0000 On 31/07/2015 22:15, "dtls-iot on behalf of Hannes Tschofenig" wrote: >The updated draft can be found at: >https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profil >e/draft-ietf-dice-profile-14.txt (FWIW) side-by-side diff available at: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.ietf.= or g/id/draft-ietf-dice-profile-13.txt&url2=3Dhttps://raw.githubusercontent.co= m/ hannestschofenig/tschofenig-ids/master/dice-profile/draft-ietf-dice-profile -14.txt Cheers, t