From nobody Mon Dec 1 00:25:22 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB831A1AA2 for ; Mon, 1 Dec 2014 00:25:20 -0800 (PST) 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 jl2aCMWbPaAR for ; Mon, 1 Dec 2014 00:25:18 -0800 (PST) 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 31BE31A0199 for ; Mon, 1 Dec 2014 00:25:18 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LgISa-1YGNAL1Q1M-00ndWF; Mon, 01 Dec 2014 09:25:13 +0100 Message-ID: <547C25E8.3050003@gmx.net> Date: Mon, 01 Dec 2014 09:25:12 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Mattsson , "dtls-iot@ietf.org" References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KOpNxX8maObPlX5S1lriw1cuxFOWRqITu" X-Provags-ID: V03:K0:qPvxyP1ReczbiBOjpoBd7AfpDcDcVoXg1Ma633gX4No1M12i2Ru GVvPjMlBdfddcy5IISwT7EVRmMZ0d4NVM7YGqP22YbS034DHzkz1xQ8X3cC1/d6n/5sqH7j ANe7Iraq8sEimRQiLYS5AVX4ov8WEzaQ1BufCKwJCWigJZ4flclvE6y4UfTIP7gEDLnQLfp 4EOWQwwBtdxNvcCXM8PvA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/RexqkXYd7yPsWp7DzbvrMpkVPNg Subject: Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 01 Dec 2014 08:25:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KOpNxX8maObPlX5S1lriw1cuxFOWRqITu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, thanks for your feedback. I believe from the responses so far we can say the following: * We recommend the use of AEAD ciphersuites (such as AES-CCM today and maybe haCha20-Poly1305 in the near future). * Chip manufacturers should make AES primitive available to developers via APIs so that they can benefit from the hardware support when they develop security mechanisms at the application layer. * Chip manufacturers need to be aware that cryptographic protocols change over time. Providing software update mechanisms (when the implementation is in software on the chip rather than in hardware) and providing building blocks in hardware (rather than complete solutions) is likely to be better in the long term. Ciao Hannes On 11/19/2014 04:07 PM, John Mattsson wrote: > Hi, >=20 > Agreeing with Hannes on HTTP/2 for IoT. >=20 > While AES-CCM is better for small devices, AES-GCM is faster on large > devices. See for example (https://eprint.iacr.org/2014/186.pdf, Table 4= , > =E2=80=9Csingle message=E2=80=9D). I also think it would be a bad idea = for HTTP/2 to > require implementation of a cipher suite with only a 8 byte authenticat= ion > tag. The IoT devices that implements HTTP/2 can probably take the cost = of > implementing GCM as well. >=20 > Concerning UTA BCP, I think Roberts suggestion =E2=80=9CI think UTA sho= uld state > the use of approved AEAD ciphers as BCP=E2=80=9D makes sense. >=20 > Another aspect is that we will probably soon have ChaCha20-Poly1305 as = a > new AEAD cipher:=20 > https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-03 >=20 > I suspect this to be popular for IoT devices without HW support for AES= , > and it strengthens the case for UTA BCP to not recommend just GCM but a= ll > approved AEAD ciphers. >=20 > Cheers, > John >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --KOpNxX8maObPlX5S1lriw1cuxFOWRqITu 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 iQEcBAEBCgAGBQJUfCXoAAoJEGhJURNOOiAtUBAH+gIbR54g7QKjRWCoeqlkD9CS bGRWBQO8sFWFf20CmvUaR0zaDuBot3imYNSUpfT/2jAlFUSeTpyg6ofzDcdRUFw3 w8Ot0HCaEawzhHn3wAH0LZciUyacsIxyc5A42XXD4unhYi+5E5Z7kmiFM3ePhLqZ 4aCjzEwo9azoSHFrc6y/l0FGACZM35saBveRkGD5MSE9x8SOMqas4DszFLPmfk1E qsvMPYaWT5ftlRlfdOWdt07V8fM3t1cn76JFNlNSBVPMq+sEK/2jPxLbd/6TzuQA 6HZeTNY2g1g/VG7RnphatbqLrCF3/6jUFxWzCjFyYTBcw9criKxHLLtMKB/UWYQ= =N7Qf -----END PGP SIGNATURE----- --KOpNxX8maObPlX5S1lriw1cuxFOWRqITu-- From nobody Mon Dec 1 05:48:06 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6F01A1BC2 for ; Mon, 1 Dec 2014 05:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDpos6va1XHb for ; Mon, 1 Dec 2014 05:48:01 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::758]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A74A1A1BC6 for ; Mon, 1 Dec 2014 05:48:00 -0800 (PST) Received: from DBXPR04CA0013.eurprd04.prod.outlook.com (10.141.8.141) by DB4PR04MB0640.eurprd04.prod.outlook.com (10.242.221.152) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 1 Dec 2014 13:47:35 +0000 Received: from AM1FFO11FD020.protection.gbl (2a01:111:f400:7e00::176) by DBXPR04CA0013.outlook.office365.com (2a01:111:e400:9414::13) with Microsoft SMTP Server (TLS) id 15.1.26.15 via Frontend Transport; Mon, 1 Dec 2014 13:47:35 +0000 Received: from mail.philips.com (206.191.240.52) by AM1FFO11FD020.mail.protection.outlook.com (10.174.64.209) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Mon, 1 Dec 2014 13:47:33 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.179]) by DBXPRD9003HT001.MGDPHG.emi.philips.com ([141.251.25.206]) with mapi id 14.16.0472.000; Mon, 1 Dec 2014 13:47:33 +0000 From: "Kumar, Sandeep" To: Dorothy Gellert , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 Thread-Index: AQHP/gXVw9xpZjMyBUy6BdrSguDsz5x6sRkg Date: Mon, 1 Dec 2014 13:47:32 +0000 Message-ID: References: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> In-Reply-To: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153EA6A363DBXPRD9003MB059_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com; X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(428002)(374574003)(85714005)(189002)(199003)(5423002)(84326002)(87936001)(120916001)(92726001)(33656002)(2656002)(97736003)(19617315012)(101416001)(106116001)(46102003)(107046002)(15202345003)(92566001)(44976005)(69596002)(104016003)(105586002)(99396003)(19580395003)(84676001)(86362001)(19625215002)(6806004)(19300405004)(68736004)(76176999)(50986999)(54356999)(71186001)(55846006)(64706001)(66066001)(20776003)(16236675004)(4396001)(15975445006)(21056001)(31966008)(77156002)(512954002)(106466001)(95666004)(81156004)(77096004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR04MB0640; H:mail.philips.com; FPR:; SPF:None; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0640; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0640; X-Forefront-PRVS: 0412A98A59 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0640; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/30E_RjKAA6zpYX88-m7ENyGZjZQ Cc: Zach Shelby , Hannes Tschofenig Subject: Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 01 Dec 2014 13:48:04 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153EA6A363DBXPRD9003MB059_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes I read through the latest version at https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile= /draft-ietf-dice-profile-06.txt My main reason to look at it again is to identify issues if a (D)TLS profil= ed Client would work with an existing non-profiled (D)TLS Server. I assume = this to be a valid scenario since I did not explicitly see any mention of n= ot using a profiled client with existing servers. 1) Section 6.1 says For use with this profile the PSK identities SHOULD NOT assume a structured format (as domain names, Distinguished Names, or IP addresses have) and a bit-by-bit comparison operation can then be used by the server-side infrastructure. Does this require a change on the server side? As an alternative you can al= so suggest that the (existing) servers continue to store the PSK-Identity e= ncoded as defined in RFC4279 which would still pass the check if done as in= RFC4279. 2) Section 6.3 says IoT devices MUST provide support for a server certificate chain of at least 3 not including the trust anchor and MAY reject connections from servers offering chains longer than 3. Can you clarify what would happen after rejecting the connection? Should a = fatal alert message be sent and if so which one? Regards Sandeep ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_BE6D13F6A4554947952B39008B0DC0153EA6A363DBXPRD9003MB059_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes

 <= /p>

I read through the latest= version at

https://github.com/hannestschofenig/tschofenig-ids/blob/= master/dice-profile/draft-ietf-dice-profile-06.txt

 <= /p>

My main reason to look at= it again is to identify issues if a (D)TLS profiled Client would work with= an existing non-profiled (D)TLS Server. I assume this to be a valid scenario since I did not explicitly see any mention of not usin= g a profiled client with existing servers.

 <= /p>

1)  &= nbsp;   Section 6.1 says<= o:p>

For use with this profile the

PSK identities SHOULD NOT assume a structured format= (as domain

names, Distinguished Names, or IP addresses have) an= d a bit-by-bit

comparison operation can then be used by the server-= side

infrastructure.

Does this require a change on the server side? As an alternative yo= u can also suggest that the (existing) servers continue to store the PSK-Identity encoded as defined in RFC4279 which would still pas= s the check if done as in RFC4279.

 <= /span>

2)  &= nbsp;   Section 6.3 says<= o:p>

IoT devices MUST provide support for a server certif= icate chain of at

least 3 not including the trust anchor and MAY rejec= t connections

from servers offering chains longer than 3.

Can you clarify what woul= d happen after rejecting the connection? Should a fatal alert message be se= nt and if so which one?

 <= /p>

 <= /p>

Regards

Sandeep

 <= /p>

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_BE6D13F6A4554947952B39008B0DC0153EA6A363DBXPRD9003MB059_-- From nobody Mon Dec 1 06:45:06 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4D61A1BC2 for ; Mon, 1 Dec 2014 06:45:05 -0800 (PST) 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 w0LR3QaYqCsP for ; Mon, 1 Dec 2014 06:45:04 -0800 (PST) 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 9B5C71A0173 for ; Mon, 1 Dec 2014 06:45:03 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LwrS8-1Xxf5i3fIG-016OMy; Mon, 01 Dec 2014 15:44:55 +0100 Message-ID: <547C7EE5.8040401@gmx.net> Date: Mon, 01 Dec 2014 15:44:53 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , Dorothy Gellert , "dtls-iot@ietf.org" References: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ihqgaI5tU6EfJGs2FpPQTXip0GVRMOvJs" X-Provags-ID: V03:K0:6MrqOSOAB8iL/PUCWTeTY9fQ0xsOVnVn5BTZGCrDnQo2x99/v2Z mMkHiQ96OJHL7Eo2Zy+0uVv5mF9UENXDqdDSJnzyFTKYazrNbQUNbAEnK0To20ZDCw5mH50 A38ImEmxDfCvUBDVH/EmzeE5x/4X1B+/LwgmbX+2y/jbYyBgMVZq+je0BACkhyKvACqe93B 4qQdNJD0aqm87OHxhmmCQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Zc9mQbwjj_N1oo6CupBcxKEFmWo Cc: Zach Shelby Subject: Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 01 Dec 2014 14:45:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ihqgaI5tU6EfJGs2FpPQTXip0GVRMOvJs Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sandeep, thanks for your comments. On 12/01/2014 02:47 PM, Kumar, Sandeep wrote: > Hi Hannes >=20 > =20 >=20 > I read through the latest version at >=20 > https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-pro= file/draft-ietf-dice-profile-06.txt >=20 > =20 >=20 > My main reason to look at it again is to identify issues if a (D)TLS > profiled Client would work with an existing non-profiled (D)TLS Server.= > I assume this to be a valid scenario since I did not explicitly see any= > mention of not using a profiled client with existing servers. Of course, there are a number of ways this could lead to a failed exchange. One obvious reason is a mismatch of ciphersuites supported by the client and the server. For example, a client only supporting AES-CCM will not be able to talk to a server that does not support it at all. For the extensions, however, the issue is less dramatic since the client will propose them and a server who does not understand them will ignore them and consequently the client will have to fall-back to a more chatty exchange. >=20 > =20 >=20 > 1) Section 6.1 says >=20 > For use with this profile the >=20 > PSK identities SHOULD NOT assume a structured format (as domain >=20 > names, Distinguished Names, or IP addresses have) and a bit-by-bit >=20 > comparison operation can then be used by the server-side >=20 > infrastructure. >=20 > Does this require a change on the server side? As an alternative you ca= n > also suggest that the (existing) servers continue to store the > PSK-Identity encoded as defined in RFC4279 which would still pass the > check if done as in RFC4279. This should not lead to any changes on the server-side infrastructure. >=20 > =20 >=20 > 2) Section 6.3 says >=20 > IoT devices MUST provide support for a server certificate chain of at >=20 > least 3 not including the trust anchor and MAY reject connections >=20 > from servers offering chains longer than 3. >=20 > Can you clarify what would happen after rejecting the connection? Shoul= d > a fatal alert message be sent and if so which one? Very good question. There is no alert error message that exactly fits this error condition but the 'certificate_unknown' alert message would fit according to the description. Alternatively, we could define a new error message but I am not sure it will provide us a lot of benefit to allow the server to learn that the certificate chain was too long. Note that this does not require any changes at the server-side code but rather in the way how it is operated (in the sense that one can obtain certificates that fulfill this requirement). Ciao Hannes >=20 > =20 >=20 > =20 >=20 > Regards >=20 > Sandeep >=20 > =20 >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or reproductio= n > of this message is strictly prohibited and may be unlawful. If you are > not the intended recipient, please contact the sender by return e-mail > and destroy all copies of the original message. --ihqgaI5tU6EfJGs2FpPQTXip0GVRMOvJs 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 iQEcBAEBCgAGBQJUfH7lAAoJEGhJURNOOiAtJcQH/RB3gJVZRj3MJfV2u1UY9BcR mL+7oUVeL7mPsA13zC16ypnCj43slL+n5c/0FL6yTTMBgYIUQAz7CcnajWJvRjML 8QUSGM3y66aXsyJf605ea/G30w+q34DSeQz3vIe+Uu4oj1ypQrKr2TkFKhdNJjsj iD6TVwUtEyg9tjxyDtaZ8YFmiU7wdWyRFedRNUWP70u8q8Qp2B+tAgWQgbgndZyv KmwoZQeKA1Cc2KAjkbAc2NftKBuN9vUDG+sbLKZ8oep9er7TxSU3Urk8QVpOLtZh fyC5k6p6wOwUvSdfMTNHeRjKm7GunBkX0H6e428KNzYCzEeOjx5lHZdqnFeP9lY= =P9Cp -----END PGP SIGNATURE----- --ihqgaI5tU6EfJGs2FpPQTXip0GVRMOvJs-- From nobody Tue Dec 2 01:35:44 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8A31A19EF for ; Tue, 2 Dec 2014 01:35:43 -0800 (PST) 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 GlHfPLs46MYr for ; Tue, 2 Dec 2014 01:35:41 -0800 (PST) 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 3506A1A1A2C for ; Tue, 2 Dec 2014 01:35:41 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MFMEG-1XhUFi2t9w-00EKaR for ; Tue, 02 Dec 2014 10:35:38 +0100 Message-ID: <547D87E9.1040106@gmx.net> Date: Tue, 02 Dec 2014 10:35:37 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.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="Ni8lGfXXdcGlb7sQsuabQweS1GCRaDgjl" X-Provags-ID: V03:K0:vZgx0lMQ99nBSwz27lXpAsKDWxWmihYL3eQcLq9ofYD/ZA6/FEE LrheGOH4xJpWuHl1cPWvOhKHhLhCjEywTOAuNp7CFOCWu9G5Ek7Ua3k6pBdhCsAXLwzg4eo IGItyyOlbtGjTHl4RmcBVu+Maj6Ep/7f9Sf6NPlCGOTU3vS/Qsnh+kLF6SVGAIIlwU6qbap u5gVcz6DGs4uJu0fZbBNg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/3zWBwXcv9J-mmiemdoi9kvh6Nnc Subject: [Dtls-iot] Constrained Server (again) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 09:35:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ni8lGfXXdcGlb7sQsuabQweS1GCRaDgjl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have tried to come up with some text for the constrained server case and I am wondering whether it addresses the comments raised earlier (or are we are talking past each other). ------ 4. Constrained Servers When a constrained client uploads sensor data to a server infrastructure it may use CoAP by pushing the data via a POST to a pre-configured endpoint on the server. In certain circumstances this might be too limiting and additional functionality is needed, as shown in Figure 1. Figure 1 shows a sensor starting with a DTLS exchange with a resource server to register available resources. The initial DTLS interaction between the sensor, acting as a DTLS client, and the resource server, acting as a DTLS server, will be a full DTLS handshake. Once this handshake is complete both parties have established the DTLS record layer, which can subsequently be used to secure the CoAP message exchange, which starts with a the resource registration. Details about the resource registry capabilities can be found in [I-D.ietf-core-resource-directory]. After some time (assuming that the client regularly refreshes its registration) the resource server receives a request (not shown) from an application to retrieve the temperature information from the sensor. This request is relayed by the resource directory to the sensor using a GET message exchange. The already established DTLS record layer can be used to secure the message exchange. Resource Sensor Directory ------ --------- +--- | | ClientHello --------> | client_certificate_type F| server_certificate_type U| L| <------- HelloVerifyRequest L| | ClientHello --------> D| client_certificate_type T| server_certificate_type L| S| ServerHello | client_certificate_type H| server_certificate_type A| Certificate N| ServerKeyExchange D| CertificateRequest S| <-------- ServerHelloDone H| A| Certificate K| ClientKeyExchange E| CertificateVerify | [ChangeCipherSpec] | Finished --------> | | [ChangeCipherSpec] | <-------- Finished +--- +--- ///+ C| \ D O| Req: POST coap://rd.example.com/rd?ep=3Dnode1 \ T A| Payload: \ L P| ;ct=3D41; \ S | rt=3D"temperature-c";if=3D"sensor", \ R| ;ct=3D41; \ R D| rt=3D"light-lux";if=3D"sensor" \ E | --------> \ C R| \ O E| \ R G| Res: 2.01 Created \ D .| <-------- Location: /rd/4521 \ | \ L +--- \ A \ Y * \ E * (time passes) \ R * \ +--- \ P C| \ R O| Req: GET coaps://sensor.example.com/temp \ O A| <-------- \ T P| \ E | Res: 2.05 Content \ C G| Payload: \ T E| 25.5 --------> \ E T| \ D +--- ///+ Figure 1: DTLS/CoAP exchange using Resource Directory. --Ni8lGfXXdcGlb7sQsuabQweS1GCRaDgjl 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 iQEcBAEBCgAGBQJUfYfqAAoJEGhJURNOOiAtuMsH/A9YXeP4hhitkdE7PlmqMLBL j98ARYgiWgJ5F1z3aLMeEvXU7BQKpob1MAEqsUDFCn9exiuNtDzN0ZYTbGOCmWuq +Yz95DVbz4maSgL5Yafvh4wcIiZbNzZApRfNdczHPrY/oxZcQ+cwEr6+qYoc/wHT RJbb/km6C5muvH8NFkbqwhErZARaKerrLqzcs2PkZNokYLNdkH6v5jx6Q1wto0JM C6mnuS2lL45STydL7gLzQgkm7jSbayDexI+kAHPtanEvJMxaG0eF181hPffiCl3I xsaIeBhBrj7o+McDFT5t9Tf/LB7DVoHNkRUB/x7N/NhUBkS+I/qHoztFBnyv7zE= =zO5+ -----END PGP SIGNATURE----- --Ni8lGfXXdcGlb7sQsuabQweS1GCRaDgjl-- From nobody Tue Dec 2 03:55:26 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA941A1AE2 for ; Tue, 2 Dec 2014 03:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2KnslFmCob8k for ; Tue, 2 Dec 2014 03:55:22 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20101A1ACC for ; Tue, 2 Dec 2014 03:55:21 -0800 (PST) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 12:55:16 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 12:55:19 +0100 From: "Kovatsch Matthias" To: Hannes Tschofenig , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Constrained Server (again) Thread-Index: AQHQDhNbJk1JBLYbaEi96GuQIIbchpx8K51g Date: Tue, 2 Dec 2014 11:55:18 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B52BA0C9E1@MBX110.d.ethz.ch> References: <547D87E9.1040106@gmx.net> In-Reply-To: <547D87E9.1040106@gmx.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/LMDByxhMNyzsAsjgPm7ffBhhq7k Subject: Re: [Dtls-iot] Constrained Server (again) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 11:55:25 -0000 RGVhciBIYW5uZXMNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB5b3UgYXJlIGZpeGVkIG9uIHRoZSBP TUEgTFdNMk0gdXNlIGNhc2UuIFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzIHRoZSBzcGVjaWFs IGNhc2Ugd2hlcmUgdGhlIFJEIGlzIGFsc28gYW4gaW50ZXJtZWRpYXJ5IHRoYXQgZm9yd2FyZHMg YWxsIHJlcXVlc3RzIGFuZCBpcyB0aGUgb25seSByZW1vdGUgZW5kcG9pbnQgZm9yIHRoZSBzZW5z b3IuIFRoaXMgaXMsIGhvd2V2ZXIsIG9ubHkgdGhlIGNhc2UgZm9yIGFwcGxpY2F0aW9ucyBpbXBs ZW1lbnRpbmcgdGhlIE9NQSBzcGVjaWZpY2F0aW9uISBJdCBpcyBhIHZlcnkgZ29vZCBwYXR0ZXJu LCBidXQgaXQgaXMgbm90IHRoZSBvbmx5IG9uZS4NCg0KVGhlIGdlbmVyYWwgdXNlIGNhc2UgaW4g dGhlIENvUkUgV0cgaXMgdGhlIGZvbGxvd2luZzogU2Vuc29yLCBSRCwgYXBwbGljYXRpb24gZW5k cG9pbnQsIGFuZCBwb3RlbnRpYWwgaW50ZXJtZWRpYXJpZXMgYXJlIGNvbXBsZXRlbHkgaW5kZXBl bmRlbnQuIFRoZSBzZW5zb3IgaXMgcHJpbWFyaWx5IGEgQ29BUCBzZXJ2ZXIgdGhhdCBwcm92aWRl cyBhY2Nlc3MgdG8gaXRzIHNlbnNvcnMgdGhyb3VnaCBXZWIgcmVzb3VyY2VzLiBUbyByZWdpc3Rl ciB3aXRoIHRoZSBSRCAoaGVyZSB0aGUgc2Vuc29yIGlzIGEgQ29BUCBjbGllbnQpLCBpdCBwZXJm b3JtcyBhIGZ1bGwgRFRMUyBoYW5kc2hha2UgYXMgRFRMUyBjbGllbnQuIExhdGVyIHRoZSBhcHBs aWNhdGlvbiBlbmRwb2ludCBkaXNjb3ZlcnMgdGhlIHNlbnNvciB0aHJvdWdoIHRoZSBSRC4gVG8g aW50ZXJhY3Qgd2l0aCB0aGUgc2Vuc29yLCB0aGUgYXBwbGljYXRpb24gZW5kcG9pbnQgcGVyZm9y bXMgYSBuZXcgZnVsbCBoYW5kc2hha2UgYXMgRFRMUyBjbGllbnQgd2hlcmUgdGhlIHNlbnNvciBt dXN0IGFjdCBhcyBEVExTIHNlcnZlci4gVGhlIGFwcGxpY2F0aW9uIGlzIGNvbW11bmljYXRpbmcg d2l0aCB0aGUgc2Vuc29yIGRpcmVjdGx5LCB0aGF0IGlzLCB3aXRob3V0IHRoZSBSRCBpbnZvbHZl ZC4gVGhpcyB1c2UgY2FzZSBpcyByZWxldmFudCBmb3IgY29udmVyZ2luZyBpbmZyYXN0cnVjdHVy ZXMgYW5kIHBlZXItdG8tcGVlciBpbnRlcmFjdGlvbiAodXN1YWxseSBpbiBsb2NhbCBuZXR3b3Jr cykuDQoNCkFsdGVybmF0aXZlbHksIHRoZSBhcHBsaWNhdGlvbiBlbmRwb2ludCBjb3VsZCBkaXNj b3ZlciB0aGUgc2Vuc29yIHRocm91Z2ggbXVsdGljYXN0IGRpc2NvdmVyeS4gSGVyZSwgdGhlIHNl bnNvciByZXNwb25kcyB0byBjb2FwIHJlcXVlc3RzIGFuZCByZXR1cm5zIGEgbGlzdCBvZiBjb2Fw cyBsaW5rcyB0byBpdHMgcmVzb3VyY2VzIGluIHRoZSBDb1JFIExpbmsgRm9ybWF0Lg0KDQpCZXN0 IHJlZ2FyZHMNCk1hdHRoaWFzDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGR0bHMtaW90IFttYWlsdG86ZHRscy1pb3QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEhhbm5lcyBUc2Nob2ZlbmlnDQpTZW50OiBEaWVuc3RhZywgMi4gRGV6ZW1iZXIgMjAxNCAxMDoz Ng0KVG86IGR0bHMtaW90QGlldGYub3JnDQpTdWJqZWN0OiBbRHRscy1pb3RdIENvbnN0cmFpbmVk IFNlcnZlciAoYWdhaW4pDQoNCkkgaGF2ZSB0cmllZCB0byBjb21lIHVwIHdpdGggc29tZSB0ZXh0 IGZvciB0aGUgY29uc3RyYWluZWQgc2VydmVyIGNhc2UgYW5kIEkgYW0gd29uZGVyaW5nIHdoZXRo ZXIgaXQgYWRkcmVzc2VzIHRoZSBjb21tZW50cyByYWlzZWQgZWFybGllciAob3IgYXJlIHdlIGFy ZSB0YWxraW5nIHBhc3QgZWFjaCBvdGhlcikuDQoNCi0tLS0tLQ0KDQoNCjQuIENvbnN0cmFpbmVk IFNlcnZlcnMNCg0KV2hlbiBhIGNvbnN0cmFpbmVkIGNsaWVudCB1cGxvYWRzIHNlbnNvciBkYXRh IHRvIGEgc2VydmVyIGluZnJhc3RydWN0dXJlIGl0IG1heSB1c2UgQ29BUCBieSBwdXNoaW5nIHRo ZSBkYXRhIHZpYSBhIFBPU1QgdG8gYSBwcmUtY29uZmlndXJlZCBlbmRwb2ludCBvbiB0aGUgc2Vy dmVyLiBJbiBjZXJ0YWluIGNpcmN1bXN0YW5jZXMgdGhpcyBtaWdodCBiZSB0b28gbGltaXRpbmcg YW5kIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBpcyBuZWVkZWQsIGFzIHNob3duIGluIEZpZ3Vy ZSAxLg0KDQpGaWd1cmUgMSBzaG93cyBhIHNlbnNvciBzdGFydGluZyB3aXRoIGEgRFRMUyBleGNo YW5nZSB3aXRoIGEgcmVzb3VyY2Ugc2VydmVyIHRvIHJlZ2lzdGVyIGF2YWlsYWJsZSByZXNvdXJj ZXMuIFRoZSBpbml0aWFsIERUTFMgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgc2Vuc29yLCBhY3Rp bmcgYXMgYSBEVExTIGNsaWVudCwgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIGFjdGluZyBhcyBh IERUTFMgc2VydmVyLCB3aWxsIGJlIGEgZnVsbCBEVExTIGhhbmRzaGFrZS4gT25jZSB0aGlzIGhh bmRzaGFrZSBpcyBjb21wbGV0ZSBib3RoIHBhcnRpZXMgaGF2ZSBlc3RhYmxpc2hlZCB0aGUgRFRM UyByZWNvcmQgbGF5ZXIsIHdoaWNoIGNhbiBzdWJzZXF1ZW50bHkgYmUgdXNlZCB0byBzZWN1cmUg dGhlIENvQVAgbWVzc2FnZSBleGNoYW5nZSwgd2hpY2ggc3RhcnRzIHdpdGggYSB0aGUgcmVzb3Vy Y2UgcmVnaXN0cmF0aW9uLiBEZXRhaWxzIGFib3V0IHRoZSByZXNvdXJjZSByZWdpc3RyeSBjYXBh YmlsaXRpZXMgY2FuIGJlIGZvdW5kIGluIFtJLUQuaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9y eV0uDQoNCkFmdGVyIHNvbWUgdGltZSAoYXNzdW1pbmcgdGhhdCB0aGUgY2xpZW50IHJlZ3VsYXJs eSByZWZyZXNoZXMgaXRzDQpyZWdpc3RyYXRpb24pIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcmVjZWl2 ZXMgYSByZXF1ZXN0IChub3Qgc2hvd24pIGZyb20gYW4gYXBwbGljYXRpb24gdG8gcmV0cmlldmUg dGhlIHRlbXBlcmF0dXJlIGluZm9ybWF0aW9uIGZyb20gdGhlIHNlbnNvci4NClRoaXMgcmVxdWVz dCBpcyByZWxheWVkIGJ5IHRoZSByZXNvdXJjZSBkaXJlY3RvcnkgdG8gdGhlIHNlbnNvciB1c2lu ZyBhIEdFVCBtZXNzYWdlIGV4Y2hhbmdlLiBUaGUgYWxyZWFkeSBlc3RhYmxpc2hlZCBEVExTIHJl Y29yZCBsYXllciBjYW4gYmUgdXNlZCB0byBzZWN1cmUgdGhlIG1lc3NhZ2UgZXhjaGFuZ2UuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXNvdXJj ZQ0KICAgIFNlbnNvciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERpcmVj dG9yeQ0KICAgIC0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t LS0tLS0tLQ0KDQogICstLS0NCiAgfA0KICB8IENsaWVudEhlbGxvICAgICAgICAgICAgIC0tLS0t LS0tPg0KICB8IGNsaWVudF9jZXJ0aWZpY2F0ZV90eXBlDQogRnwgc2VydmVyX2NlcnRpZmljYXRl X3R5cGUNCiBVfA0KIEx8ICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tICAgIEhlbGxv VmVyaWZ5UmVxdWVzdA0KIEx8DQogIHwgQ2xpZW50SGVsbG8gICAgICAgICAgICAgLS0tLS0tLS0+ DQogRHwgY2xpZW50X2NlcnRpZmljYXRlX3R5cGUNCiBUfCBzZXJ2ZXJfY2VydGlmaWNhdGVfdHlw ZQ0KIEx8DQogU3wgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNl cnZlckhlbGxvDQogIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsaWVudF9jZXJ0 aWZpY2F0ZV90eXBlDQogSHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlcl9j ZXJ0aWZpY2F0ZV90eXBlDQogQXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIENlcnRpZmljYXRlDQogTnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFNlcnZlcktleUV4Y2hhbmdlDQogRHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQ2VydGlmaWNhdGVSZXF1ZXN0DQogU3wgICAgICAgICAgICAgICAgICAgICAgICAgPC0t LS0tLS0tICAgICAgU2VydmVySGVsbG9Eb25lDQogSHwNCiBBfCBDZXJ0aWZpY2F0ZQ0KIEt8IENs aWVudEtleUV4Y2hhbmdlDQogRXwgQ2VydGlmaWNhdGVWZXJpZnkNCiAgfCBbQ2hhbmdlQ2lwaGVy U3BlY10NCiAgfCBGaW5pc2hlZCAgICAgICAgICAgICAgICAtLS0tLS0tLT4NCiAgfA0KICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtDaGFuZ2VDaXBoZXJTcGVjXQ0KICB8 ICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLSAgICAgICAgICAgICBGaW5pc2hlZA0K ICArLS0tDQoNCiAgKy0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLy8vKw0KIEN8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBcIEQNCiBPfCBSZXE6IFBPU1QgY29hcDovL3JkLmV4YW1wbGUuY29t L3JkP2VwPW5vZGUxICAgICAgICAgICAgXCBUDQogQXwgUGF5bG9hZDogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgTA0KIFB8IDwvdGVtcD47Y3Q9NDE7ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcIFMNCiAgfCAgICBydD0idGVt cGVyYXR1cmUtYyI7aWY9InNlbnNvciIsICAgICAgICAgICAgICAgICAgICAgXA0KIFJ8IDwvbGln aHQ+O2N0PTQxOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcIFINCiBE fCAgICBydD0ibGlnaHQtbHV4IjtpZj0ic2Vuc29yIiAgICAgICAgICAgICAgICAgICAgICAgICAg XCBFDQogIHwgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0+ICAgICAgICAgICAgICAg ICAgICAgIFwgQw0KIFJ8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBcIE8NCiBFfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXCBSDQogR3wgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUmVzOiAyLjAxIENyZWF0ZWQgIFwgRA0KIC58ICAgICAgICAgICAgICAgICAgICAg ICAgIDwtLS0tLS0tLSAgTG9jYXRpb246IC9yZC80NTIxICBcDQogIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgTA0KICArLS0tICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcIEENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCBZ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAqICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFwgRQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKiAodGltZSBwYXNzZXMpICAgICAg ICAgICAgICAgICBcIFINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgXA0KICArLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBcIFANCiBDfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCBSDQogT3wgICAgICAgICAgICAgIFJlcTog R0VUIGNvYXBzOi8vc2Vuc29yLmV4YW1wbGUuY29tL3RlbXAgIFwgTw0KIEF8ICAgICAgICAgICAg ICAgICAgICAgICAgIDwtLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICBcIFQNCiBQfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCBFDQog IHwgUmVzOiAgMi4wNSBDb250ZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFwgQw0KIEd8IFBheWxvYWQ6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBcIFQNCiBFfCAyNS41ICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0+ICAgICAg ICAgICAgICAgICAgICAgXCBFDQogVHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFwgRA0KICArLS0tICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAvLy8rDQoNCiAgICBGaWd1cmUgMTogRFRMUy9Db0FQ IGV4Y2hhbmdlIHVzaW5nIFJlc291cmNlIERpcmVjdG9yeS4NCg0KDQo= From nobody Tue Dec 2 04:07:34 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D191A1AF1 for ; Tue, 2 Dec 2014 04:07:31 -0800 (PST) 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 ji6JYnHkGwoY for ; Tue, 2 Dec 2014 04:07:29 -0800 (PST) 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 B07021A1AEB for ; Tue, 2 Dec 2014 04:07:28 -0800 (PST) Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LoEwL-1YNyF730uX-00gGyg; Tue, 02 Dec 2014 13:07:20 +0100 Message-ID: <547DAB77.2010702@gmx.net> Date: Tue, 02 Dec 2014 13:07:19 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kovatsch Matthias , "dtls-iot@ietf.org" References: <547D87E9.1040106@gmx.net> <55877B3AFB359744BA0F2140E36F52B52BA0C9E1@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52BA0C9E1@MBX110.d.ethz.ch> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lGMGQKM0PusejsM8lucQ1xNPWDOwirJlf" X-Provags-ID: V03:K0:nbqzwKcxprkgbzmUlqQ5Q7t7BqvhKqPuMCZhAfrnuv/wXzIQTYt 8PKpJk53y26wgrWo5Mj5RtqHZB/Emu5nrFqCb9qJrHWOFLSmP6INXlvBivIu+gNoQcaggI9 7bmKuGxRVcTRD2FPrT2tt7eekdf8gfbv2mCeGM9OJkNMUAT4I1QNE5moBItCl5lUYYRp+p1 jNICZNlgOL2SCtjVCJ2aQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/tqaKAoFAeQelBcbekEz2q8Ii9jU Subject: Re: [Dtls-iot] Constrained Server (again) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:07:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lGMGQKM0PusejsM8lucQ1xNPWDOwirJlf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Matthias, On 12/02/2014 12:55 PM, Kovatsch Matthias wrote: > Dear Hannes >=20 > It seems to me that you are fixed on the OMA LWM2M use case. What you > are describing is the special case where the RD is also an > intermediary that forwards all requests and is the only remote > endpoint for the sensor. This is, however, only the case for > applications implementing the OMA specification! It is a very good > pattern, but it is not the only one. I had intentionally chosen that case since I wanted to demonstrate a case that allows me to have the sensor as a DTLS client and the cloud infrastructure running the DTLS server. >=20 > The general use case in the CoRE WG is the following: Sensor, RD, > application endpoint, and potential intermediaries are completely > independent. The sensor is primarily a CoAP server that provides > access to its sensors through Web resources. To register with the RD > (here the sensor is a CoAP client), it performs a full DTLS handshake > as DTLS client. Later the application endpoint discovers the sensor > through the RD. To interact with the sensor, the application endpoint > performs a new full handshake as DTLS client where the sensor must > act as DTLS server. > The application is communicating with the sensor > directly, that is, without the RD involved. This use case is relevant > for converging infrastructures and peer-to-peer interaction (usually > in local networks). >=20 > Alternatively, the application endpoint could discover the sensor > through multicast discovery. Here, the sensor responds to coap > requests and returns a list of coaps links to its resources in the > CoRE Link Format. Thanks. This made it quite clear what you want. This will obviously lead to a different profile since some of the assumptions I made in the current text are less likely to be valid in such a scenario. I will figure out what the "impact" for the text actually is. Ciao Hannes >=20 > Best regards Matthias >=20 >=20 > -----Original Message----- From: dtls-iot > [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Hannes Tschofenig=20 > Sent: Dienstag, 2. Dezember 2014 10:36 To: dtls-iot@ietf.org Subject: > [Dtls-iot] Constrained Server (again) >=20 > I have tried to come up with some text for the constrained server > case and I am wondering whether it addresses the comments raised > earlier (or are we are talking past each other). >=20 > ------ >=20 >=20 > 4. Constrained Servers >=20 > When a constrained client uploads sensor data to a server > infrastructure it may use CoAP by pushing the data via a POST to a > pre-configured endpoint on the server. In certain circumstances this > might be too limiting and additional functionality is needed, as > shown in Figure 1. >=20 > Figure 1 shows a sensor starting with a DTLS exchange with a resource > server to register available resources. The initial DTLS interaction > between the sensor, acting as a DTLS client, and the resource server, > acting as a DTLS server, will be a full DTLS handshake. Once this > handshake is complete both parties have established the DTLS record > layer, which can subsequently be used to secure the CoAP message > exchange, which starts with a the resource registration. Details > about the resource registry capabilities can be found in > [I-D.ietf-core-resource-directory]. >=20 > After some time (assuming that the client regularly refreshes its=20 > registration) the resource server receives a request (not shown) from > an application to retrieve the temperature information from the > sensor. This request is relayed by the resource directory to the > sensor using a GET message exchange. The already established DTLS > record layer can be used to secure the message exchange. >=20 > Resource Sensor Directory=20 > ------ --------- >=20 > +--- | | ClientHello --------> | client_certificate_type=20 > F| server_certificate_type U| L| <------- > HelloVerifyRequest L| | ClientHello --------> D| > client_certificate_type T| server_certificate_type L| S| > ServerHello | client_certificate_type=20 > H| server_certificate_type A| > Certificate N| > ServerKeyExchange D| > CertificateRequest S| <-------- > ServerHelloDone H| A| Certificate K| ClientKeyExchange E| > CertificateVerify | [ChangeCipherSpec] | Finished > --------> | | [ChangeCipherSpec]=20 > | <-------- Finished +--- >=20 > +--- ///+ C| > \ D O| Req: POST coap://rd.example.com/rd?ep=3Dnode1 \ T A| > Payload: \ L P| > ;ct=3D41; \ S | > rt=3D"temperature-c";if=3D"sensor", \ R| > ;ct=3D41; \ R D| > rt=3D"light-lux";if=3D"sensor" \ E | > --------> \ C R| > \ O E| \ R G| > Res: 2.01 Created \ D .| <-------- > Location: /rd/4521 \ | > \ L +--- \ A \ Y=20 > * \ E * (time passes) \ > R * \ +--- > \ P C| \ R O| > Req: GET coaps://sensor.example.com/temp \ O A| > <-------- \ T P| > \ E | Res: 2.05 Content \ C G| > Payload: \ T E| 25.5 > --------> \ E T| > \ D +--- ///+ >=20 > Figure 1: DTLS/CoAP exchange using Resource Directory. >=20 >=20 --lGMGQKM0PusejsM8lucQ1xNPWDOwirJlf 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 iQEcBAEBCgAGBQJUfat3AAoJEGhJURNOOiAtc08H/1RSf9RNPIMROXIU9KcnGJ7e U/HBAURKfXjVgN1Sgw07qx4i51va6wJ/Yu/SNZo/IwQZR0zBx7IhzkrJsocap02K BgnU4pSDOXpzBcVHS6PKiVbOUHd+QshkS0fIqsWo/GTq0XQNTw4Pn/NICqUCCWc4 ySKUo5QzJpc8Bh+rRHZJcXrKQnc9nhwrzXc5VE/AHn++aAl7O7OA7q4oDPiU+eVG L0cL8qM275a/xMrTuDcpQUS+bwlbj6uCoWJP+qRFh/YdnEDcZYt7BsbqOow+lrmO EbI+o9th1maNkMaAqwiMrCL98xfZzcDEeFbsytQUVNKE4CRyO921T04X5vPHuL4= =x6V1 -----END PGP SIGNATURE----- --lGMGQKM0PusejsM8lucQ1xNPWDOwirJlf-- From nobody Tue Dec 2 07:04:26 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5EC1ACE01 for ; Tue, 2 Dec 2014 07:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Nej4V1bk9b8T for ; Tue, 2 Dec 2014 07:04:20 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B5D1A1BDD for ; Tue, 2 Dec 2014 07:04:15 -0800 (PST) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:04:10 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 16:04:13 +0100 From: "Kovatsch Matthias" To: Hannes Tschofenig , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Constrained Server (again) Thread-Index: AQHQDhNbJk1JBLYbaEi96GuQIIbchpx8K51g///4g4CAAD968A== Date: Tue, 2 Dec 2014 15:04:11 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B52BA0E362@MBX110.d.ethz.ch> References: <547D87E9.1040106@gmx.net> <55877B3AFB359744BA0F2140E36F52B52BA0C9E1@MBX110.d.ethz.ch> <547DAB77.2010702@gmx.net> In-Reply-To: <547DAB77.2010702@gmx.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/nPITlY2_V8v7tMFFjhmogPMNzII Subject: Re: [Dtls-iot] Constrained Server (again) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:04:23 -0000 PiA+IEl0IHNlZW1zIHRvIG1lIHRoYXQgeW91IGFyZSBmaXhlZCBvbiB0aGUgT01BIExXTTJNIHVz ZSBjYXNlLiBXaGF0IHlvdQ0KPiA+IGFyZSBkZXNjcmliaW5nIGlzIHRoZSBzcGVjaWFsIGNhc2Ug d2hlcmUgdGhlIFJEIGlzIGFsc28gYW4NCj4gPiBpbnRlcm1lZGlhcnkgdGhhdCBmb3J3YXJkcyBh bGwgcmVxdWVzdHMgYW5kIGlzIHRoZSBvbmx5IHJlbW90ZQ0KPiA+IGVuZHBvaW50IGZvciB0aGUg c2Vuc29yLiBUaGlzIGlzLCBob3dldmVyLCBvbmx5IHRoZSBjYXNlIGZvcg0KPiA+IGFwcGxpY2F0 aW9ucyBpbXBsZW1lbnRpbmcgdGhlIE9NQSBzcGVjaWZpY2F0aW9uISBJdCBpcyBhIHZlcnkgZ29v ZA0KPiA+IHBhdHRlcm4sIGJ1dCBpdCBpcyBub3QgdGhlIG9ubHkgb25lLg0KPiANCj4gSSBoYWQg aW50ZW50aW9uYWxseSBjaG9zZW4gdGhhdCBjYXNlIHNpbmNlIEkgd2FudGVkIHRvIGRlbW9uc3Ry YXRlIGEgY2FzZQ0KPiB0aGF0IGFsbG93cyBtZSB0byBoYXZlIHRoZSBzZW5zb3IgYXMgYSBEVExT IGNsaWVudCBhbmQgdGhlIGNsb3VkDQo+IGluZnJhc3RydWN0dXJlIHJ1bm5pbmcgdGhlIERUTFMg c2VydmVyLg0KDQpPa2F5LCBidXQgdGhlbiB0aGUgaGVhZGluZyAiQ29uc3RyYWluZWQgU2VydmVy cyIgaXMgdmVyeSBtaXNsZWFkaW5nIGJlY2F1c2UgdGhlcmUgaXMgbm8gY29uc3RyYWluZWQgRFRM UyBzZXJ2ZXIgYW5kIHRoZSBzZW5zb3IgY2Fubm90IGFjdCBhcyBzdGFuZC1hbG9uZSBDb0FQIHNl cnZlci4NCg0KPiA+IFRoZSBnZW5lcmFsIHVzZSBjYXNlIGluIHRoZSBDb1JFIFdHIGlzIHRoZSBm b2xsb3dpbmc6IFNlbnNvciwgUkQsDQo+ID4gYXBwbGljYXRpb24gZW5kcG9pbnQsIGFuZCBwb3Rl bnRpYWwgaW50ZXJtZWRpYXJpZXMgYXJlIGNvbXBsZXRlbHkNCj4gPiBpbmRlcGVuZGVudC4gVGhl IHNlbnNvciBpcyBwcmltYXJpbHkgYSBDb0FQIHNlcnZlciB0aGF0IHByb3ZpZGVzDQo+ID4gYWNj ZXNzIHRvIGl0cyBzZW5zb3JzIHRocm91Z2ggV2ViIHJlc291cmNlcy4gVG8gcmVnaXN0ZXIgd2l0 aCB0aGUgUkQNCj4gPiAoaGVyZSB0aGUgc2Vuc29yIGlzIGEgQ29BUCBjbGllbnQpLCBpdCBwZXJm b3JtcyBhIGZ1bGwgRFRMUyBoYW5kc2hha2UNCj4gPiBhcyBEVExTIGNsaWVudC4gTGF0ZXIgdGhl IGFwcGxpY2F0aW9uIGVuZHBvaW50IGRpc2NvdmVycyB0aGUgc2Vuc29yDQo+ID4gdGhyb3VnaCB0 aGUgUkQuIFRvIGludGVyYWN0IHdpdGggdGhlIHNlbnNvciwgdGhlIGFwcGxpY2F0aW9uIGVuZHBv aW50DQo+ID4gcGVyZm9ybXMgYSBuZXcgZnVsbCBoYW5kc2hha2UgYXMgRFRMUyBjbGllbnQgd2hl cmUgdGhlIHNlbnNvciBtdXN0IGFjdA0KPiA+IGFzIERUTFMgc2VydmVyLg0KPiA+IFRoZSBhcHBs aWNhdGlvbiBpcyBjb21tdW5pY2F0aW5nIHdpdGggdGhlIHNlbnNvciBkaXJlY3RseSwgdGhhdCBp cywNCj4gPiB3aXRob3V0IHRoZSBSRCBpbnZvbHZlZC4gVGhpcyB1c2UgY2FzZSBpcyByZWxldmFu dCBmb3IgY29udmVyZ2luZw0KPiA+IGluZnJhc3RydWN0dXJlcyBhbmQgcGVlci10by1wZWVyIGlu dGVyYWN0aW9uICh1c3VhbGx5IGluIGxvY2FsDQo+ID4gbmV0d29ya3MpLg0KPiA+DQo+ID4gQWx0 ZXJuYXRpdmVseSwgdGhlIGFwcGxpY2F0aW9uIGVuZHBvaW50IGNvdWxkIGRpc2NvdmVyIHRoZSBz ZW5zb3INCj4gPiB0aHJvdWdoIG11bHRpY2FzdCBkaXNjb3ZlcnkuIEhlcmUsIHRoZSBzZW5zb3Ig cmVzcG9uZHMgdG8gY29hcA0KPiA+IHJlcXVlc3RzIGFuZCByZXR1cm5zIGEgbGlzdCBvZiBjb2Fw cyBsaW5rcyB0byBpdHMgcmVzb3VyY2VzIGluIHRoZQ0KPiA+IENvUkUgTGluayBGb3JtYXQuDQo+ IFRoYW5rcy4gVGhpcyBtYWRlIGl0IHF1aXRlIGNsZWFyIHdoYXQgeW91IHdhbnQuDQo+IA0KPiBU aGlzIHdpbGwgb2J2aW91c2x5IGxlYWQgdG8gYSBkaWZmZXJlbnQgcHJvZmlsZSBzaW5jZSBzb21l IG9mIHRoZSBhc3N1bXB0aW9ucyBJDQo+IG1hZGUgaW4gdGhlIGN1cnJlbnQgdGV4dCBhcmUgbGVz cyBsaWtlbHkgdG8gYmUgdmFsaWQgaW4gc3VjaCBhIHNjZW5hcmlvLiBJIHdpbGwNCj4gZmlndXJl IG91dCB3aGF0IHRoZSAiaW1wYWN0IiBmb3IgdGhlIHRleHQgYWN0dWFsbHkgaXMuDQoNCkluIHRo aXMgY2FzZSwgdGhlIGRvY3VtZW50IHNob3VsZCBzaW1wbHkgbWFrZSBjbGVhciB0aGF0IGl0IGlz IGEgcHJvZmlsZSBmb3IgY29uc3RyYWluZWQgRFRMUyBjbGllbnRzIGFuZCBub3QgZm9yIGNvbnN0 cmFpbmVkIERUTFMgaW4gZ2VuZXJhbC4gTXkgbWFpbiBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQg ZHJhZnQgaXMgdGhhdCBpdCBpbXBsaWNpdGx5IGZvcmNlcyBhbGwgQ29BUCBzb2x1dGlvbnMgaW50 byB0aGUgT01BIExXTTJNIG1vZGVsLiBUaGVyZSBpcyBubyBwcm9ibGVtIHdoZW4gd2UgZXhwbGlj aXRseSBzcGxpdCBpdCB1cCBpbnRvIGEgRFRMUyBjbGllbnQgYW5kIGEgRFRMUyBzZXJ2ZXIgcHJv ZmlsZS4NCg0KSW1wbGVtZW50YXRpb24tIGFuZCBjb2RlLXNpemUtd2lzZSB0aGVyZSBpcyBhbG1v c3Qgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIERUTFMgY2xpZW50IGFuZCBzZXJ2ZXIgcm9sZS4gQm90 aCBzaWRlcyBoYXZlIHRvIGltcGxlbWVudCB0aGUgaGFuZHNoYWtlIHN0YXRlIG1hY2hpbmUuIExv b2tpbmcgYXQgdGhlIG51bWJlcnMgZnJvbSBodHRwczovL3Blb3BsZS5pbmYuZXRoei5jaC9tc2hh ZmFnaC9tYXN0ZXJfdGhlc2lzX0hvc3NlaW5fU2hhZmFnaF9QS0NfaW5fdGhlX0lvVC5wZGYjODAg KGRvY3VtZW50IHBhZ2UgNjgpLCBjbGllbnRzIGNvbnN1bWUgc2xpZ2h0bHkgbW9yZSBtZW1vcnkg ZHVlIHRvIHRoZSBDbGllbnRIZWxsbyBjb250cm9sIHBhdGguIFRoZSBvdmVyaGVhZCBvZiBpbXBs ZW1lbnRpbmcgYm90aCByb2xlcyBpcyBtaW5pbWFsLCBzaW5jZSB0aGUgc3RhdGUgbWFjaGluZSBh bmQgYWxsIGNyeXB0byBmdW5jdGlvbnMgYXJlIHNoYXJlZC4NCg0KQ2lhbw0KTWF0dGhpYXMNCg0K From nobody Sun Dec 7 10:22:37 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B32C1A87E9 for ; Sun, 7 Dec 2014 10:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8SFlv378gOtp for ; Sun, 7 Dec 2014 10:22:22 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DCC1A0053 for ; Sun, 7 Dec 2014 10:22:20 -0800 (PST) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 7 Dec 2014 19:22:18 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0195.001; Sun, 7 Dec 2014 19:22:18 +0100 From: "Kovatsch Matthias" To: "dtls-iot@ietf.org" Thread-Topic: DTLS fragmentation Thread-Index: AdASSahij4lCxFyqSSKY5B7G5kKSJA== Date: Sun, 7 Dec 2014 18:22:17 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.171.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/MoGc2YlgixXTARsnz1xcMqrx7Pw Subject: [Dtls-iot] DTLS fragmentation X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 18:22:30 -0000 Dear list I have been wondering if the DTLS Profile should constrain the fragmentatio= n mechanism of DTLS. It is somewhat "chaotic," as it allows fragments of di= fferent size that can also overlap. This can be quite a burden for constrai= ned devices. Shouldn't the DTLS Profile maybe simplify this for DICE? I am = aware that this will then also affect the cloud side. Another problem that came up during interoperability tests is the assignmen= t of DTLS messages to UDP datagrams. When the system has large enough buffe= rs, the DTLS implementation can simply put all messages of a flight into a = single datagram. Systems with highly constrained buffers, however, often ex= pect each message in a separate datagram. Should the Profile do something a= bout this? (Sorry if I simply overread this in the draft!) Ciao Matthias From nobody Sun Dec 7 12:03:27 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594581A0278 for ; Sun, 7 Dec 2014 12:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZkrOLXaSyO9 for ; Sun, 7 Dec 2014 12:03:22 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD941A00E2 for ; Sun, 7 Dec 2014 12:03:20 -0800 (PST) Received: from AM3PR04CA0022.eurprd04.prod.outlook.com (10.242.16.22) by DB4PR04MB0639.eurprd04.prod.outlook.com (10.242.221.151) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sun, 7 Dec 2014 20:02:56 +0000 Received: from AM1FFO11FD022.protection.gbl (2a01:111:f400:7e00::107) by AM3PR04CA0022.outlook.office365.com (2a01:111:e400:8814::22) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Sun, 7 Dec 2014 20:02:55 +0000 Received: from mail.philips.com (206.191.240.52) by AM1FFO11FD022.mail.protection.outlook.com (10.174.64.211) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Sun, 7 Dec 2014 20:02:55 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.179]) by DBXPRD9003HT003.MGDPHG.emi.philips.com ([141.251.25.208]) with mapi id 14.16.0472.000; Sun, 7 Dec 2014 20:02:55 +0000 From: "Kumar, Sandeep" To: Kovatsch Matthias , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] DTLS fragmentation Thread-Index: AQHQEljJKc/mrb7pQ0aRwuC9zln/xA== Date: Sun, 7 Dec 2014 20:02:54 +0000 Message-ID: <0tsqa3or6712ym0vkr7hrcdx.1417982569275@email.android.com> References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0tsqa3or6712ym0vkr7hrcdx1417982569275emailandroidcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(428002)(479174003)(374574003)(189002)(199003)(85714005)(43066003)(99396003)(68736005)(81156004)(19625215002)(107886001)(62966003)(106116001)(106466001)(77156002)(120916001)(102836002)(15975445007)(97736003)(71186001)(101416001)(69596002)(84326002)(84676001)(19617315012)(104016003)(33646002)(6806004)(512954002)(46102003)(19580405001)(19580395003)(87936001)(2656002)(86362001)(53806999)(21056001)(20776003)(107046002)(16236675004)(95246002)(105586002)(30436002)(54356999)(76176999)(50986999)(64706001)(4396001)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR04MB0639; H:mail.philips.com; FPR:; SPF:None; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0639; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0639; X-Forefront-PRVS: 04180B6720 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0639; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/9BFONtGtgc-ejdoyZ_tnvWUvhzM Subject: Re: [Dtls-iot] DTLS fragmentation X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Kumar, Sandeep" List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 20:03:24 -0000 --_000_0tsqa3or6712ym0vkr7hrcdx1417982569275emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Both very valid observations we also came across and would be nice to be in= the profile. Sandeep Sent from Mobile -------- Original message -------- From: Kovatsch Matthias Date: 2014/12/07 19:22 (GMT+01:00) To: dtls-iot@ietf.org Subject: [Dtls-iot] DTLS fragmentation Dear list I have been wondering if the DTLS Profile should constrain the fragmentatio= n mechanism of DTLS. It is somewhat "chaotic," as it allows fragments of di= fferent size that can also overlap. This can be quite a burden for constrai= ned devices. Shouldn't the DTLS Profile maybe simplify this for DICE? I am = aware that this will then also affect the cloud side. Another problem that came up during interoperability tests is the assignmen= t of DTLS messages to UDP datagrams. When the system has large enough buffe= rs, the DTLS implementation can simply put all messages of a flight into a = single datagram. Systems with highly constrained buffers, however, often ex= pect each message in a separate datagram. Should the Profile do something a= bout this? (Sorry if I simply overread this in the draft!) Ciao Matthias _______________________________________________ dtls-iot mailing list dtls-iot@ietf.org https://www.ietf.org/mailman/listinfo/dtls-iot ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_0tsqa3or6712ym0vkr7hrcdx1417982569275emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

Both very valid observations we also came across and would be nice to = be in the profile.

Sandeep


Sent from Mobile



-------- Original message --------
From: Kovatsch Matthias <kovatsch@inf.ethz.ch>
Date: 2014/12/07 19:22 (GMT+01:00)
To: dtls-iot@ietf.org
Subject: [Dtls-iot] DTLS fragmentation


Dear list

I have been wondering if the DTLS Profile should constrain the fragmentatio= n mechanism of DTLS. It is somewhat "chaotic," as it allows fragm= ents of different size that can also overlap. This can be quite a burden fo= r constrained devices. Shouldn't the DTLS Profile maybe simplify this for DICE? I am aware that this will then also = affect the cloud side.

Another problem that came up during interoperability tests is the assignmen= t of DTLS messages to UDP datagrams. When the system has large enough buffe= rs, the DTLS implementation can simply put all messages of a flight into a = single datagram. Systems with highly constrained buffers, however, often expect each message in a separate data= gram. Should the Profile do something about this? (Sorry if I simply overre= ad this in the draft!)

Ciao
Matthias


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

The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_0tsqa3or6712ym0vkr7hrcdx1417982569275emailandroidcom_-- From nobody Sun Dec 7 15:47:34 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D11A1B0B for ; Sun, 7 Dec 2014 15:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfwr_mgg19G8 for ; Sun, 7 Dec 2014 15:47:31 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297441A1B0A for ; Sun, 7 Dec 2014 15:47:31 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id x12so2699056qac.32 for ; Sun, 07 Dec 2014 15:47:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wk8Ntz1gXVbWOhn3ZHdHKv1bLTP4FJUU9qGwHoU7Fq8=; b=PWZT4uS8oNhM4wCQOcoQKe4El/FxFjt25sIhDcZUsCpYHVofvPvhjpJE/+vuIGHRvw XKTN/fzHb1qHX/uZX87Co6f5FxAQEvEQ+pla2LFb3z4UvW/eaxA8O+VNoyDoHj2vqLF6 rTuLWktDRCreLW1kaUIsRxmNRkJU1n/a7Jrj5S6DS+sF/StZUtbdj57VfZF6LmDaoWoj DH1wkGY3jeORuotxw04bvtg8abB4A8GevznzMv6Zvl6IjU+VSYtFeBYY5n2zkrjhI3yr jQfI/d2S1q8VLgUGTtZU6Hw0WkXU5rgUIftMx+/HCq5joFEoucOvOtcFGkn4EvzE4VGb JRTw== X-Gm-Message-State: ALoCoQkWXKB29alQHIi5hSW5TJgeFlmBZDFDJrlnYeaHAF4GLORKV6nAXMR1iKvqDHmkhtUqhgWQ X-Received: by 10.224.172.131 with SMTP id l3mr48064584qaz.32.1417996050345; Sun, 07 Dec 2014 15:47:30 -0800 (PST) Received: from [192.168.1.105] (c-69-255-115-150.hsd1.md.comcast.net. [69.255.115.150]) by mx.google.com with ESMTPSA id k4sm36416467qaf.0.2014.12.07.15.47.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Dec 2014 15:47:30 -0800 (PST) Message-ID: <5484E6FC.2010208@nthpermutation.com> Date: Sun, 07 Dec 2014 18:47:08 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/iWnuk__Na9uyHYk6fDpyzaPJ_dU Subject: Re: [Dtls-iot] DTLS fragmentation X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 23:47:32 -0000 On 12/7/2014 1:22 PM, Kovatsch Matthias wrote: > Dear list > > I have been wondering if the DTLS Profile should constrain the fragmentation mechanism of DTLS. It is somewhat "chaotic," as it allows fragments of different size that can also overlap. This can be quite a burden for constrained devices. Shouldn't the DTLS Profile maybe simplify this for DICE? I am aware that this will then also affect the cloud side. > > Another problem that came up during interoperability tests is the assignment of DTLS messages to UDP datagrams. When the system has large enough buffers, the DTLS implementation can simply put all messages of a flight into a single datagram. Systems with highly constrained buffers, however, often expect each message in a separate datagram. Should the Profile do something about this? (Sorry if I simply overread this in the draft!) > > Ciao > Matthias > > The major problem with the above is that both sides need to know how to do this and there isn't support in the base standard (DTLS) for this approach. That makes it difficult to write a profile. What would need to be done is to write a draft describing how to use an extension to signal this behavior. Then that specification could be referenced by the profile. There's also the problem that although "server" initiated extensions are technically possible, there isn't actually a worked example and you would need both client and server versions of a "please don't fragment in a weird way" extension. The latter issue you mention is probably manageable. What you're talking about is splitting a "flight" of messages across a number of UDP datagrams. Section 3.2.3 of the DTLS spec already deals with this I believe. Is there something else that you think needs to be said? From nobody Mon Dec 8 00:54:39 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F0B1A7010 for ; Mon, 8 Dec 2014 00:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nlV3VYWyyne for ; Mon, 8 Dec 2014 00:54:37 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C1D1A8034 for ; Mon, 8 Dec 2014 00:54:37 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so3183304qcy.4 for ; Mon, 08 Dec 2014 00:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fw1m2U6NSsfJ/wyuOc8qT7lghMwAgIfUVo9P7ZZBmpo=; b=NkHYztsBsckR0rqDoQYUM/FCc4z1jvnJbkdyrKK1NghWJtPGrJec+P/+nhvuI31z7m ZQzxf2u1Sww+d+ceSqdyEeY03iydAbF6fAn6wR8jo08sSiT7H8pWtXW2mzJXiHJAe6qs WYyZ6tQNypmH4I8YWN/V8nojg0Dj8icGcCckC5QTzj2ejKazyNy+7cq5hmC4bYu4L/Vv AyuN/kodyUGJvnD7PacnEV+KDWHQOvKqbkzGgv1yw3HofhiAp+UyLKPjTEypFctymYgv oRp+QjgiCrXwmrAY69YV4Nom14UR8oHfKa5Ni4D7uEDq7KSLgDmZYbHK1XOg4E0wht+4 0zuQ== MIME-Version: 1.0 X-Received: by 10.224.40.72 with SMTP id j8mr50942107qae.59.1418028876332; Mon, 08 Dec 2014 00:54:36 -0800 (PST) Received: by 10.229.222.131 with HTTP; Mon, 8 Dec 2014 00:54:36 -0800 (PST) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> Date: Mon, 8 Dec 2014 09:54:36 +0100 Message-ID: From: Nikos Mavrogiannopoulos To: Kovatsch Matthias Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/cvScehMRvqlI-y7eraW3JlJ4dbg Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 08 Dec 2014 08:54:38 -0000 On Sun, Dec 7, 2014 at 7:22 PM, Kovatsch Matthias wrote: > Dear list > > I have been wondering if the DTLS Profile should constrain the fragmentation mechanism of DTLS. It is somewhat "chaotic," as it allows fragments of different size that can also overlap. Could you elaborate on that. On which part of DTLS do you refer to? Is that the handshake message fragmentation mechanism? If yes, I don't see how that fits your description of the fragmentation mechanism: "When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges. ... The ranges SHOULD NOT overlap." regards, Nikos From nobody Mon Dec 8 01:42:36 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472921A896A; Mon, 8 Dec 2014 01:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrhrArDELKiF; Mon, 8 Dec 2014 01:42:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 249C41A87AD; Mon, 8 Dec 2014 01:42:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208094234.29522.81973.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 01:42:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Sk4G9FtoZtpVZ8RnX_nfuFHWM8w Cc: dtls-iot@ietf.org Subject: [Dtls-iot] I-D Action: draft-ietf-dice-profile-06.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 09:42:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DTLS In Constrained Environments Working Group of the IETF. Title : A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet of Things Authors : Hannes Tschofenig Thomas Fossati Filename : draft-ietf-dice-profile-06.txt Pages : 35 Date : 2014-12-08 Abstract: This document defines a DTLS 1.2 profile that is suitable for Internet of Things applications and is reasonably implementable on many constrained devices. A common design pattern in IoT deployments is the use of a constrained device (typically providing sensor data) that interacts with the web infrastructure. This document focuses on this particular pattern. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dice-profile-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dice-profile-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 01:48:06 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED801A89B5 for ; Mon, 8 Dec 2014 01:48:05 -0800 (PST) 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 3QC2HDS1oYAL for ; Mon, 8 Dec 2014 01:48:03 -0800 (PST) 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 4D2931A89B3 for ; Mon, 8 Dec 2014 01:48:03 -0800 (PST) Received: from [192.168.131.135] ([80.92.119.109]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lmr1w-1XULrZ1vum-00h8m8 for ; Mon, 08 Dec 2014 10:48:01 +0100 Message-ID: <548573D0.4040407@gmx.net> Date: Mon, 08 Dec 2014 10:48:00 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.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="P7eAi0T82Bifdpp79wiQigv6MUSxq2e77" X-Provags-ID: V03:K0:qWzxRb24/ZYOJfbllF+KbYJm0fkL3bebHOpCwGg8tGAabBLzMwH IjSQ45zZ5NHGIQMGV7EAEcZc5ugIzuAUM8o6DH8SLc2RYEMfLQFvJeMYPka0evQEwhwHN0x gXlBvYyMALjcb6YnwWcohEX3hfyMel+FT8FkocSfa638bpkW5EiAOJ8YOkK9Q3nH9eyUoiE T+RSGrDxz19pd1nSG80wg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/iNACYWiCD2Mw7kEoLGRFRFeLKg4 Subject: [Dtls-iot] draft-ietf-dice-profile-06 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, 08 Dec 2014 09:48:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P7eAi0T82Bifdpp79wiQigv6MUSxq2e77 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I just submitted version -06 of the DTLS profile document. It is a snapshot release to document what issues have been incorporated. Here is the new version: http://www.ietf.org/id/draft-ietf-dice-profile-06.txt The following issues have been resolved with this version: #13 Key Length Recommendations #15 Timeouts #12 Perfect Forward Secrecy #20 TLS False Start #14 Signature Algorithm Extension Here are the open issues: http://trac.tools.ietf.org/wg/dice/trac/report/1 There are also review comments, which I have not addressed yet (from Ekr and Paul Bakker). Ciao Hannes --P7eAi0T82Bifdpp79wiQigv6MUSxq2e77 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 iQEcBAEBCgAGBQJUhXPQAAoJEGhJURNOOiAtrqwH+QFzEgBWCgpSrJVNZ8I2iJ6T 1KV2N0LtRFJU1C08huS9SoO3cizqJhKvEVMFJo0nSdGj1SL9DR8sGD8IvYByrDz3 Kxfn2GyYlZxnUefVM8tvCqwleZa6yujDGDeZWWkubP7s5+JvsdGPpKjryQaFIdB8 Qk+X6t7cg7BcDIF23eMOogxQ4SagYfNaqaCeTfOJtWH9OTVuCJ54lJMIqMUHYgQg gVWh2S2MWKkotKRT7okF+/bKnPUdBCwwlJbhG/ek7fURpUdn1Iht30YXh261PIOm a9dHvthh7iOVxRg1X5dDZZWoure0KIsF6vUbEveeh43Q8VZWV1OrId2C4esChkc= =0piX -----END PGP SIGNATURE----- --P7eAi0T82Bifdpp79wiQigv6MUSxq2e77-- From nobody Mon Dec 8 03:26:31 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82CC1A0174 for ; Mon, 8 Dec 2014 03:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up-L5KC9JuLH for ; Mon, 8 Dec 2014 03:26:27 -0800 (PST) Received: from simplewebmail.uom.gr (simplewebmail.uom.gr [195.251.213.88]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27BC1A0183 for ; Mon, 8 Dec 2014 03:26:26 -0800 (PST) Received: from simplewebmail.uom.gr (simplewebmail.uom.gr [127.0.0.1]) by simplewebmail.uom.gr (Postfix) with ESMTP id 31F9611DE069 for ; Mon, 8 Dec 2014 13:26:25 +0200 (EET) Received: from 88.0.172.103 (SquirrelMail authenticated user economid) by simplewebmail.uom.gr with HTTP; Mon, 8 Dec 2014 13:26:25 +0200 Message-ID: Date: Mon, 8 Dec 2014 13:26:25 +0200 From: economid@uom.gr To: dtls-iot@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-7 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/oh0Xsra4_h0xbmZ08_YzqaasNgw Subject: [Dtls-iot] CfPs: IoT/CPS-Security 2015 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, 08 Dec 2014 11:26:29 -0000 [Apologies for receiving multiple copies] CfPs: IoT/CPS-Security 2015 http://conta.uom.gr/IoTCPSsecurity2015/cfp.html The First IEEE International Workshop on Security and Privacy for Internet of Things and Cyber-Physical Systems, http://conta.uom.gr/IoTCPSsecurity2015/ organized in conjunction with IEEE International Conference on Communications (ICC 2015), 8-12 June 2015, London, UK, http://icc2015.ieee-icc.org/ IMPORTANT DATES Paper submission deadline: 10 January, 2015 Acceptance notification: 14 February, 2015 Final paper ("camera-ready"): 28 February, 2015 Workshop date: 8 June, 2015. TOPICS OF INTEREST To ensure complete coverage of the advances in this field, the 2015 IoT/CPS-Security workshop solicits original contributions in, but not limited to, the following topical areas: - Security, Privacy and Trust for IoT and CPS Systems - Secure IoT and CPS architectures - Security vulnerabilities in IoT and CPS systems - Security in Machine-to-Machine (M2M) systems - Detecting and preventing attacks in IoT devices and CPS systems - Evaluation of the Threats, Attacks and Risks in IoT and cyber-physical devices - Data Security and Privacy in the IoT - Game theory for IoT and CPS security - Security and Privacy in IoT applications and services (health care, smart cities, smart grid, safety and surveillance systems, etc.) - Security and Privacy for RFID, sensors, actuator technologies - Security in Smart Grids and Smart Spaces - Network-distributed signal processing for security solutions in CPS - Joint security and privacy aware protocol design - Test-bed and performance metrics of security solutions in CPS - Deployment and performance studies of secure CPS - Secure network control systems for CPS applications - Secure implementation of cyber-physical systems - Architectures for secure hardware/software CPS systems SUBMISSION PROCEDURE The workshop accepts only novel, previously unpublished papers. Papers should be written in English with a standard length of six (6) printed pages (10-point font) including figures, without incurring additional page charges (maximum 1 additional page with extra charge if accepted). You may use the standard IEEE Transactions templates for Microsoft Word or LaTeX formats found here. For more information, please visit the following URL: http://icc2015.ieee-icc.org/content/authors-guidelines. The edas link for paper submission is: https://edas.info/newPaper.php?c=18701&track=66317. MORE INFORMATION http://conta.uom.gr/IoTCPSsecurity2015/ **** ***** ***** ***** ***** ***** Prof. Anastasios A. Economides, http://users.uom.gr/~economid/ Director CONTA (Computer Networks & Telematics Applications) Lab, http://conta.uom.gr/conta/uk/index.htm University of Macedonia, Thessaloniki, GREECE, keynote speech on Internet of Things & Sensor Network Security : http://www.slideshare.net/economides/internet-of-thingsbyeconomideskeynotespeechatccit2014final From nobody Tue Dec 9 01:57:59 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209C01A6FFB for ; Tue, 9 Dec 2014 01:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qazpWM5g04fs for ; Tue, 9 Dec 2014 01:57:56 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE9D1A1B12 for ; Tue, 9 Dec 2014 01:57:53 -0800 (PST) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 10:57:49 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 10:57:51 +0100 From: "Kovatsch Matthias" To: Nikos Mavrogiannopoulos Thread-Topic: [Dtls-iot] DTLS fragmentation Thread-Index: AdASSahij4lCxFyqSSKY5B7G5kKSJAAco1wAADaFbpA= Date: Tue, 9 Dec 2014 09:57:50 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/aBro2Xeho1EWa5EArV47OMPKRdk Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 09 Dec 2014 09:57:58 -0000 > > I have been wondering if the DTLS Profile should constrain the > fragmentation mechanism of DTLS. It is somewhat "chaotic," as it allows > fragments of different size that can also overlap. >=20 > Could you elaborate on that. On which part of DTLS do you refer to? Is th= at > the handshake message fragmentation mechanism? If yes, I don't see how > that fits your description of the fragmentation mechanism: > "When transmitting the handshake message, the sender divides the > message into a series of N contiguous data ranges. ... The ranges SHOULD > NOT overlap." In my opinion this SHOULD NOT should be a MUST NOT for IoT devices. Further= more, it would be good to have a general idea what fragment sizes to expect= , so that the buffers can be reasonably dimensioned. Ciao Matthias From nobody Tue Dec 9 02:07:27 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67011A6FFB for ; Tue, 9 Dec 2014 02:07:24 -0800 (PST) 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 jxdJafsXI-r5 for ; Tue, 9 Dec 2014 02:07:23 -0800 (PST) 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 4548B1A7020 for ; Tue, 9 Dec 2014 02:07:23 -0800 (PST) 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 sB9A7JEq009679; Tue, 9 Dec 2014 11:07:19 +0100 (CET) Received: from aung.tzi.org (unknown [134.102.116.72]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3jxcWW0x28z4tbv; Tue, 9 Dec 2014 11:07:19 +0100 (CET) From: Olaf Bergmann To: "Kovatsch Matthias" References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> Date: Tue, 09 Dec 2014 11:07:18 +0100 In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> (Kovatsch Matthias's message of "Tue, 9 Dec 2014 09:57:50 +0000") Message-ID: <87egs9w2zt.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/d63AeDxgIb1XuEsgFu-FcyJY8A4 Cc: Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 09 Dec 2014 10:07:25 -0000 Matthias, "Kovatsch Matthias" writes: > In my opinion this SHOULD NOT should be a MUST NOT for IoT > devices. Furthermore, it would be good to have a general idea what > fragment sizes to expect, so that the buffers can be reasonably > dimensioned. I presume that constrained devices will likely have static buffers with a fixed size. I do not see how they would dynamically adjust their size. Regards Olaf From nobody Tue Dec 9 07:08:47 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570541A1EFC for ; Tue, 9 Dec 2014 07:08:46 -0800 (PST) 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 mhx9bMl1XkQQ for ; Tue, 9 Dec 2014 07:08:44 -0800 (PST) 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 7A1F31A1AAC for ; Tue, 9 Dec 2014 07:08:44 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B2F74CEE09FA1; Tue, 9 Dec 2014 15:08:39 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB9F8T2A000753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 16:08:42 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.139]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 16:08:07 +0100 From: "FOSSATI, Thomas (Thomas)" To: Hannes Tschofenig , Alexey Melnikov , Dorothy Gellert Thread-Topic: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 Thread-Index: AQHQCwPfy+3uILyvf0y08eyNjT6XmpyHXRKA Date: Tue, 9 Dec 2014 15:08:07 +0000 Message-ID: References: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> <5478657E.4030106@gmx.net> In-Reply-To: <5478657E.4030106@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.4.6.141106 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B25E8E66185F24E9C244EF63C63D602@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/EbWDEZAskHV3QbVGfoKBksnC_aQ Cc: Zach Shelby , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 09 Dec 2014 15:08:46 -0000 Hi Alexey, On 28/11/2014 12:07, "Hannes Tschofenig" wrote: >On 11/22/2014 08:08 PM, Alexey Melnikov wrote: >>In Section 18: >>=20 >> CoAP demands version 1.2 of DTLS to be used and the earlier version >> of DTLS is not supported. As such, there is no risk of downgrading >> to an older version of DTLS. The work described in >> [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to >> this environment since there is no legacy server infrastructure to >> worry about. >>=20 >> While I-D.bmoeller-tls-downgrade-scsv is not currently needed, it might >> be useful when TLS 1.3/etc gets deployed and problems are found in TLS >> 1.2. Is this something we need to worry about in long term? >>=20 > >I created an issue for this item: >https://tools.ietf.org/wg/dice/trac/ticket/21 Do you think the following might be a sensible way out? 1) We explicitly tell that the handshake MUST fail hard if a version < 1.2 is negotiated; 2) once 1.3 is published, if 1.2 turns out to be flawed then deprecate 1.2 and jointly describe the use of SCSV to avoid 1.2 fallback. Rationale: there seems to be no need for SCSV until 1.2 is shown to be broken -- if we don't allow negotiating versions less then 1.2 in the first place. Cheers, t From nobody Tue Dec 9 12:15:20 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966421A0087 for ; Tue, 9 Dec 2014 12:15:18 -0800 (PST) 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 m1tXoDxMeSIl for ; Tue, 9 Dec 2014 12:15:17 -0800 (PST) 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 C2C441A007C for ; Tue, 9 Dec 2014 12:15:16 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Md31i-1YFQ4e2o6M-00ICo8; Tue, 09 Dec 2014 21:15:14 +0100 Message-ID: <5487584E.40508@gmx.net> Date: Tue, 09 Dec 2014 21:15:10 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kovatsch Matthias , "dtls-iot@ietf.org" References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CNQPm3SEn8xJ24bOXECLhi1Fj6koK55qi" X-Provags-ID: V03:K0:wRSc4py6qZiy2y/b87osiyqY9DzqHB9I7KZROS/uppjaUZTMOMr Cqpb0XOl+Tm5WAGDFS6JN+cRkQ8+/AHweI8pejoCZtgBhg0KdpgL6mriItkVYLKkQ4qtVRk 2X6f/+Xb2qNxZv9lcEEQnoLiMG2oPjO/Tao4yI7wtV4UGb5SVkRwK7IgtXmRTJCaYJ8Gfrh v7JJlpnS/9+YwBl6NGnlg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/BwilOGPN67llNelok3q1RIOa3mw Subject: Re: [Dtls-iot] DTLS fragmentation 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, 09 Dec 2014 20:15:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CNQPm3SEn8xJ24bOXECLhi1Fj6koK55qi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Matthias, thanks for raising this issue. I would like to focus on the second issue you highlighted first. > Another problem that came up during interoperability tests is the > assignment of DTLS messages to UDP datagrams. When the system has > large enough buffers, the DTLS implementation can simply put all > messages of a flight into a single datagram. Systems with highly > constrained buffers, however, often expect each message in a separate > datagram. Should the Profile do something about this? (Sorry if I > simply overread this in the draft!) But there is clearly a tradeoff here since sending each DTLS message separately leads to more on-the-wire overhead. Certainly, if you do not have large enough buffers then you will not be able to combine multiple messages into a single UDP datagram. Where do you think text should go? What recommendation should we give? Ciao Hannes --CNQPm3SEn8xJ24bOXECLhi1Fj6koK55qi 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 iQEcBAEBCgAGBQJUh1hOAAoJEGhJURNOOiAtiiAH/RuwaIZOHOF9BXRyHLATkbyK SAoswUe+g8N/+IasgPGE8/M/zoedUnreE9hYt4+FngbSGSWApQyt6rrbBcgRR/7E kba4MpT/E7Xb1WBd7EkIJXDM7cxUqjlEiWMIwJuo41jA00Io3kktPMz2o1j9d//f nUKAqHu4cJlC2QQ68fKQ8RIsdGdBDb3HrQZMItdFSpoBdPlH5l3Fw3/Mpuhbj5fi Xht4y0og8zpzaxTTZDbqp7g5YUdryblvirCqUzB+nBFu6pQqOlF/WXFCm4nkXcLo WrmFDIw+YiyF8e/98Ufc449TgMx3eYdxxv9lBS+2e+xbp2zEJStKt7oSCy8HnIU= =EFjA -----END PGP SIGNATURE----- --CNQPm3SEn8xJ24bOXECLhi1Fj6koK55qi-- From nobody Tue Dec 9 12:20:24 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11471A8777 for ; Tue, 9 Dec 2014 12:20:22 -0800 (PST) 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 oybfPLVUYGFF for ; Tue, 9 Dec 2014 12:20:21 -0800 (PST) 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 CF47B1A0097 for ; Tue, 9 Dec 2014 12:20:20 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MexaL-1YMGcN30h7-00Ob4K; Tue, 09 Dec 2014 21:20:18 +0100 Message-ID: <54875981.6060608@gmx.net> Date: Tue, 09 Dec 2014 21:20:17 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Olaf Bergmann , Kovatsch Matthias References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> In-Reply-To: <87egs9w2zt.fsf@tzi.org> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HG3VB1VncVQGaMFnvo7Jf4gDi7quiaCrF" X-Provags-ID: V03:K0:1gj99XeWIFWrlUxOd2LEXvrJq2b/aoUu/+H4bDuQaQkTlD1arZK CkisJtQvRWf6f39YB0SOg8EX1n9Vde33u8psEWN+p+AwOUfmeIMA5ETQhHNxe+SRLRtkwLU FT1g+mwyZo7A2n3dpx3ptX63GHumSZo844I0OOopWgT0kgwgxe4WR1I6Zr8QRKfRsXDCnQo 37bg+5MQulKGt6WR1Jqaw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/bGz_e8Mh60C8QNWG7t80u5Lvaew Cc: Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 09 Dec 2014 20:20:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HG3VB1VncVQGaMFnvo7Jf4gDi7quiaCrF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Olaf, On 12/09/2014 11:07 AM, Olaf Bergmann wrote: > I presume that constrained devices will likely have static buffers with= > a fixed size. I do not see how they would dynamically adjust their size= =2E It heavily depends on your implementation preferences on how to do the memory management. Here is info about the memory model in mbed (see http://developer.mbed.org/handbook/Memory-Model) and how dynamic memory can be allocated. Ciao Hannes --HG3VB1VncVQGaMFnvo7Jf4gDi7quiaCrF 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 iQEcBAEBCgAGBQJUh1mCAAoJEGhJURNOOiAtJxoH/R2grAZEktsD9N7mjQdABubh 8t30pEkNJulaHzuMVhwo9gumXbe/cyuriIzw05urGAlROC2SbuPbx20VLO4wNek5 H4jROycEhUpx8ieI3ct/J0yYhL8NnIITYTT4OysMMcbmCD1ntPRTk2Y/ugkLzc3K ya6yWGpApVc0Jr3hRGP4ELfn9Nwj5Vr5o++rW08QkU9ggoX/AVyudWEW2NUcfijj j+Cc1MjqtY/tfQRJfGbr0kzlZUIaX5+2H/StWJAVsKv2Nev43+Uqn751rRhy423/ BCg0AY7KWtMMO+t14rOG7dEdQQBMig8NdkpsaeRQfQBejYEK3pyypCgvX9SOKgw= =R0pf -----END PGP SIGNATURE----- --HG3VB1VncVQGaMFnvo7Jf4gDi7quiaCrF-- From nobody Wed Dec 10 00:10:21 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C281A8889 for ; Wed, 10 Dec 2014 00:10:19 -0800 (PST) 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 EjwbFwLkjR-n for ; Wed, 10 Dec 2014 00:10:15 -0800 (PST) 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 6BC801A1EF8 for ; Wed, 10 Dec 2014 00:10:14 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LnUna-1XUCQ125yI-00hbt6 for ; Wed, 10 Dec 2014 09:10:11 +0100 Message-ID: <5487FFD9.5070105@gmx.net> Date: Wed, 10 Dec 2014 09:10:01 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.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="AAbq1MqqTCfJkTHtLX5F2UofILXgdO8FB" X-Provags-ID: V03:K0:O9qf8Pv05r2lO5fM0IIgkq4QuGjXlS7Q5QOnSdecdpjPJcXbekb 7T2buZF/nc1l+nf4JkyZ7XwLZjK3+F5V8oExbnmFjHSl9RYjMgmoHp3ZFaQDuUBOjkTNUXK Whg6AM2R6uTmWmetrKpdXgNuAr0el7+bSl+KghXP0ZJd3Alo+GJPpTPEWHezs17CmpriVdS MtQdqKNMigL3XvGz+nkgg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/CWdPn27UwQheHK1rp3E_6mSK0tM Subject: [Dtls-iot] Issue#19: AES CCM vs. AES GCM 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, 10 Dec 2014 08:10:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AAbq1MqqTCfJkTHtLX5F2UofILXgdO8FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I created issue#19 in response to the discussions about AES CCM vs. AES GCM and the misalignment with the UTA working group. Here is the ticket: http://trac.tools.ietf.org/wg/dice/trac/ticket/19 The recently submitted version -08 of UTA document (see=E2=80=8B http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08) talks about the relationship between the UTA document and the DTLS profile document indirectly by saying: " Some devices have hardware support for AES-CCM but not AES-GCM. There are even devices that do not support public key cryptography at all. This BCP does not cover such devices. " The UTA BCP document also points out that there are more specific document providing further information than the generic guideline documen= t. " This document does not change the mandatory-to-implement TLS cipher suite(s) prescribed by TLS or application protocols using TLS. To maximize interoperability, RFC 5246 mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly weaker than the cipher suites recommended here. Implementers should consider the interoperability gain against the loss in security when deploying that cipher suite. Other application protocols specify other cipher suites as mandatory to implement (MTI). " While further refinements of the text are in discussion the issues is being dealt with in the UTA working group. For this reason I have closed the ticket. Ciao Hannes --AAbq1MqqTCfJkTHtLX5F2UofILXgdO8FB 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 iQEcBAEBCgAGBQJUh//ZAAoJEGhJURNOOiAtvAgH/3HBD4kBE2KRTXbszeJYOg2H pdxxM6MYZyhljKgfoBnPah+bAKXUCP0ErcBGrMjP8NjIwLle9b+uX9mqYxfXtHMr Q7IXL/smeREUDIxcxq/gr46AO6enEJyZkDKuc5QdffPTHREswZF/wAfZyeGdmPce XBvJpxui82HaLEMljBII+YwzxqQC0HvpIWmdrIUhdsYctfFmmGVEBFVaM9yST3rG 3T0G9Q8sB0bCjj133rfk8ZYHWgDc+ZbLG8/mxToxdOyrF4RoIy0NWVfhPuXLonIn 0MHq8Ck3yCw66QsZOcS3vnFSdjtvKrU4iQzL3aOhiHh8B5kzZI4XXpqfW3AaInw= =PHFv -----END PGP SIGNATURE----- --AAbq1MqqTCfJkTHtLX5F2UofILXgdO8FB-- From nobody Wed Dec 10 00:10:36 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25991A1EF8 for ; Wed, 10 Dec 2014 00:10:34 -0800 (PST) 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 7ZMGF1eVC13E for ; Wed, 10 Dec 2014 00:10:29 -0800 (PST) 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 D86891A8889 for ; Wed, 10 Dec 2014 00:10:28 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MTeVY-1YOud0109w-00QVKn for ; Wed, 10 Dec 2014 09:10:26 +0100 Message-ID: <5487FFF1.7010001@gmx.net> Date: Wed, 10 Dec 2014 09:10:25 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.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="fUVs9EoOHb9u16x7QavLPocbcwI2G2RLN" X-Provags-ID: V03:K0:UMoafvDL1OSOvtwYuTzf2Ep1t7lmZOzs/9qnGHTa4SWWjtFBh6n aEm0C78CQ1vfEed4Aavn/om0OtZkYqSWBz31HT9HLs8myHCydo9M3UCT+1PzrEMJg9xT/Jo oAXblTjQaSuOxwlGCRzYKdrQTED4c0SkKYkdtpML9WzgJzGNijPwrNA9mB4HlszlEAIjjmH +JrynE7cjnCFp3RMEZAfQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/1AUk3CdVFYHp86RFqTjgOuMcOrU Subject: [Dtls-iot] Issue#17: AES-CCM nonces in DTLS records 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, 10 Dec 2014 08:10:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fUVs9EoOHb9u16x7QavLPocbcwI2G2RLN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here is a proposal for resolving issue#17: http://trac.tools.ietf.org/wg/dice/trac/ticket/17 ------ Appendix B: DTLS Record Layer Per-Packet Overhead Figure X shows the overhead for the DTLS record layer for protecting data traffic when AES-128-CCM with an 8-octet Integrity Check Value (ICV) is used. DTLS Record Layer Header................13 bytes Nonce (Explicit).........................8 bytes ICV..................................... 8 bytes ------------------------------------------------ Overhead................................29 bytes ------------------------------------------------ Figure X: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead. The DTLS record layer header has 13 octets and consists of - 1 octet content type field, - 2 octet version field, - 2 octet epoch field, - 6 octet sequence number, - 2 octet length field. The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet nonce. The salt is the "implicit" part of the nonce and is not sent in the packet. Since the nonce_explicit may be the 8 octet sequence number and, in DTLS, it is the 8 octet epoch concatenated with the 6 octet sequence number. The sequence number component of the nonce_explicit field in the record layer is an exact copy of the sequence number in the record layer header field. Hence, this leads to a duplication of 8-bytes per record. To avoid this 8-byte duplication RFC 7400 provides help with the use of the generic header compression technique for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that this header compression technique is not available when DTLS is exchanged over transports that do not use IPv6 or 6LoWPAN, such as the SMS transport described in Appendix A. --fUVs9EoOHb9u16x7QavLPocbcwI2G2RLN 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 iQEcBAEBCgAGBQJUh//xAAoJEGhJURNOOiAtdsYH/iH5WHWZgMNqa/q4X+StCfAR 5VV1eCpPDLNumEW6DxBrfIhjP8jsRX7Wnd2WfZ8HRsFK7c0DEizHn/pTj8mVyIJi FAE8W+QhCw8Yl1iVWNq19JyufxXjsqE19Qhqc9Ia5I/2zU7Z69mCAgprzEi9j6OI KLmDgKEdNKMiXgNgh8tiPh/v6vVkAp07vFCYCTJJGs5RgtYuHSO7a28YTSd19a+7 IdA4iAyDesFvJ9FKURfLpYdymYYhpha9AF6xNI5YEoNbuJXwfDXhkEutxqiJfzFY 8BUymfGbpntSKLa/i4sEW05kgIlu86FLJ6x2AhZcp0ebVXDLazRxZpaa7AbOQKA= =n79W -----END PGP SIGNATURE----- --fUVs9EoOHb9u16x7QavLPocbcwI2G2RLN-- From nobody Wed Dec 10 00:20:11 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35571A1BCE for ; Wed, 10 Dec 2014 00:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsY7crLEsuOb for ; Wed, 10 Dec 2014 00:20:01 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 45E3F1A1B23 for ; Wed, 10 Dec 2014 00:20:01 -0800 (PST) Received: from USA-SJC-GW2.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Wed, 10 Dec 2014 08:19:59 +0000 Received: from Spock.usa.Arm.com ([fe80::4116:859a:65b1:2f84]) by USA-SJC-GW2.usa.Arm.com ([::1]) with mapi; Wed, 10 Dec 2014 00:19:56 -0800 From: Zach Shelby To: Hannes Tschofenig Date: Wed, 10 Dec 2014 00:19:55 -0800 Thread-Topic: [Dtls-iot] Issue#19: AES CCM vs. AES GCM Thread-Index: AdAUUhQbJpTUWFZzRw+qgMNfg4wbew== Message-ID: References: <5487FFD9.5070105@gmx.net> In-Reply-To: <5487FFD9.5070105@gmx.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-MC-Unique: 114121008195902002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/BUOG-lZQ2oJjupH9W4amL5kZdpU Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Issue#19: AES CCM vs. AES GCM 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, 10 Dec 2014 08:20:06 -0000 SGFubmVzLA0KDQpTb3VuZHMgcmVhc29uYWJsZSB0byBjbG9zZSB0aGlzIG9uZSB0aGVuLiBUaGFu a3MgZm9yIGZvbGxvd2luZyB1cCBvbiB0aGlzIQ0KDQpaYWNoDQoNCk9uIERlYyAxMCwgMjAxNCwg YXQgMTA6MTAgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0 PiB3cm90ZToNCg0KPiBJIGNyZWF0ZWQgaXNzdWUjMTkgaW4gcmVzcG9uc2UgdG8gdGhlIGRpc2N1 c3Npb25zIGFib3V0IEFFUyBDQ00gdnMuIEFFUw0KPiBHQ00gYW5kIHRoZSBtaXNhbGlnbm1lbnQg d2l0aCB0aGUgVVRBIHdvcmtpbmcgZ3JvdXAuIEhlcmUgaXMgdGhlIHRpY2tldDoNCj4gaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvZGljZS90cmFjL3RpY2tldC8xOQ0KPg0KPiBUaGUgcmVj ZW50bHkgc3VibWl0dGVkIHZlcnNpb24gLTA4IG9mIFVUQSBkb2N1bWVudCAoc2Vl4oCLDQo+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdXRhLXRscy1iY3AtMDgpIHRhbGtz IGFib3V0IHRoZQ0KPiByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgVVRBIGRvY3VtZW50IGFuZCB0 aGUgRFRMUyBwcm9maWxlIGRvY3VtZW50DQo+IGluZGlyZWN0bHkgYnkgc2F5aW5nOg0KPg0KPiAi DQo+IFNvbWUgZGV2aWNlcyBoYXZlIGhhcmR3YXJlIHN1cHBvcnQgZm9yIEFFUy1DQ00gYnV0IG5v dCBBRVMtR0NNLg0KPiBUaGVyZSBhcmUgZXZlbiBkZXZpY2VzIHRoYXQgZG8gbm90IHN1cHBvcnQg cHVibGljIGtleSBjcnlwdG9ncmFwaHkgYXQNCj4gYWxsLiBUaGlzIEJDUCBkb2VzIG5vdCBjb3Zl ciBzdWNoIGRldmljZXMuDQo+ICINCj4NCj4gVGhlIFVUQSBCQ1AgZG9jdW1lbnQgYWxzbyBwb2lu dHMgb3V0IHRoYXQgdGhlcmUgYXJlIG1vcmUgc3BlY2lmaWMNCj4gZG9jdW1lbnQgcHJvdmlkaW5n IGZ1cnRoZXIgaW5mb3JtYXRpb24gdGhhbiB0aGUgZ2VuZXJpYyBndWlkZWxpbmUgZG9jdW1lbnQu DQo+DQo+ICINCj4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBjaGFuZ2UgdGhlIG1hbmRhdG9yeS10 by1pbXBsZW1lbnQgVExTIGNpcGhlcg0KPiBzdWl0ZShzKSBwcmVzY3JpYmVkIGJ5IFRMUyBvciBh cHBsaWNhdGlvbiBwcm90b2NvbHMgdXNpbmcgVExTLiBUbw0KPiBtYXhpbWl6ZSBpbnRlcm9wZXJh YmlsaXR5LCBSRkMgNTI0NiBtYW5kYXRlcyBpbXBsZW1lbnRhdGlvbiBvZiB0aGUNCj4gVExTX1JT QV9XSVRIX0FFU18xMjhfQ0JDX1NIQSBjaXBoZXIgc3VpdGUsIHdoaWNoIGlzIHNpZ25pZmljYW50 bHkNCj4gd2Vha2VyIHRoYW4gdGhlIGNpcGhlciBzdWl0ZXMgcmVjb21tZW5kZWQgaGVyZS4gSW1w bGVtZW50ZXJzIHNob3VsZA0KPiBjb25zaWRlciB0aGUgaW50ZXJvcGVyYWJpbGl0eSBnYWluIGFn YWluc3QgdGhlIGxvc3MgaW4gc2VjdXJpdHkgd2hlbg0KPiBkZXBsb3lpbmcgdGhhdCBjaXBoZXIg c3VpdGUuIE90aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyBzcGVjaWZ5DQo+IG90aGVyIGNpcGhl ciBzdWl0ZXMgYXMgbWFuZGF0b3J5IHRvIGltcGxlbWVudCAoTVRJKS4NCj4gIg0KPg0KPiBXaGls ZSBmdXJ0aGVyIHJlZmluZW1lbnRzIG9mIHRoZSB0ZXh0IGFyZSBpbiBkaXNjdXNzaW9uIHRoZSBp c3N1ZXMgaXMNCj4gYmVpbmcgZGVhbHQgd2l0aCBpbiB0aGUgVVRBIHdvcmtpbmcgZ3JvdXAuDQo+ DQo+IEZvciB0aGlzIHJlYXNvbiBJIGhhdmUgY2xvc2VkIHRoZSB0aWNrZXQuDQo+DQo+IENpYW8N Cj4gSGFubmVzDQo+IDxzaWduYXR1cmUuYXNjPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGR0bHMtaW90IG1haWxpbmcgbGlzdA0KPiBkdGxzLWlvdEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bHMtaW90 DQoNClphY2ggU2hlbGJ5DQpEaXJlY3RvciBvZiBUZWNobmljYWwgTWFya2V0aW5nDQpBUk0gSW50 ZXJuZXQgb2YgVGhpbmdzIEJVDQp3d3cuYXJtLmNvbQ0KVVM6ICsxICg0MDgpIDIwMy05NDM0DQpG aW5sYW5kOiArMzU4IDQwNzc5NjI5Nw0KU2t5cGU6IHpkc2hlbGJ5DQpMaW5rZWRJbjogZmkubGlu a2VkaW4uY29tL2luL3phY2hzaGVsYnkvDQoNCg0KLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gIFRoYW5rIHlvdS4NCg0KQVJNIExpbWl0ZWQsIFJlZ2lzdGVyZWQgb2ZmaWNlIDExMCBGdWxi b3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs ZXMsIENvbXBhbnkgTm86ICAyNTU3NTkwDQpBUk0gSG9sZGluZ3MgcGxjLCBSZWdpc3RlcmVkIG9m ZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVyZWQgaW4g RW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAgMjU0ODc4Mg0K From nobody Wed Dec 10 00:53:01 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758E51A014C for ; Wed, 10 Dec 2014 00:53:00 -0800 (PST) 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 UrNdf4ANjhFM for ; Wed, 10 Dec 2014 00:52:59 -0800 (PST) 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 B03531A0069 for ; Wed, 10 Dec 2014 00:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (xm3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sBA8qsZi019705; Wed, 10 Dec 2014 09:52:54 +0100 (CET) Received: from alma.local.informatik.uni-bremen.de (robin.informatik.uni-bremen.de [134.102.218.1]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2FD999CB; Wed, 10 Dec 2014 09:52:54 +0100 (CET) X-Mailer: emacs 25.0.50.1 (via feedmail 11-beta-1 I) From: Carsten Bormann To: Hannes Tschofenig References: <5487FFF1.7010001@gmx.net> Date: Wed, 10 Dec 2014 09:52:41 +0100 In-Reply-To: <5487FFF1.7010001@gmx.net> (Hannes Tschofenig's message of "Wed, 10 Dec 2014 09:10:25 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/FC9iYZBkBnfppclvAfSdVpcwZck Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Issue#17: AES-CCM nonces in DTLS records 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, 10 Dec 2014 08:53:00 -0000 Hannes Tschofenig writes: > Note that this header compression technique is not available when DTLS > is exchanged over transports that do not use IPv6 or 6LoWPAN, such as > the SMS transport described in Appendix A. Interesting. Should we think about a version of GHC for SMS? Gruesse, Carsten From nobody Wed Dec 10 03:33:02 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A341A1B57 for ; Wed, 10 Dec 2014 03:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JhOpFU7mI8c for ; Wed, 10 Dec 2014 03:32:57 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE1C1A1B46 for ; Wed, 10 Dec 2014 03:32:56 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 790989A4005; Wed, 10 Dec 2014 06:32:45 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id eJ9B-zC3bqP2; Wed, 10 Dec 2014 06:32:24 -0500 (EST) Received: from [198.180.150.150] (unknown [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 78DBA9A4001; Wed, 10 Dec 2014 06:32:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Russ Housley In-Reply-To: <5487FFD9.5070105@gmx.net> Date: Wed, 10 Dec 2014 06:32:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <62A49E31-7CEC-4449-A482-72632CAC5699@vigilsec.com> References: <5487FFD9.5070105@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/V_MnugELDIJc_oa1CYJmwTsoITw Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Issue#19: AES CCM vs. AES GCM 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, 10 Dec 2014 11:32:59 -0000 Seems fine. I would like to see larger devices support AES-CCM, but = that is not an issue for this working group. Russ On Dec 10, 2014, at 3:10 AM, Hannes Tschofenig wrote: > I created issue#19 in response to the discussions about AES CCM vs. = AES > GCM and the misalignment with the UTA working group. Here is the = ticket: > http://trac.tools.ietf.org/wg/dice/trac/ticket/19 >=20 > The recently submitted version -08 of UTA document (see=E2=80=8B > http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08) talks about the > relationship between the UTA document and the DTLS profile document > indirectly by saying: >=20 > " > Some devices have hardware support for AES-CCM but not AES-GCM. > There are even devices that do not support public key cryptography at > all. This BCP does not cover such devices. > " >=20 > The UTA BCP document also points out that there are more specific > document providing further information than the generic guideline = document. >=20 > " > This document does not change the mandatory-to-implement TLS cipher > suite(s) prescribed by TLS or application protocols using TLS. To > maximize interoperability, RFC 5246 mandates implementation of the > TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly > weaker than the cipher suites recommended here. Implementers should > consider the interoperability gain against the loss in security when > deploying that cipher suite. Other application protocols specify > other cipher suites as mandatory to implement (MTI). > " >=20 > While further refinements of the text are in discussion the issues is > being dealt with in the UTA working group. >=20 > For this reason I have closed the ticket. >=20 > Ciao > Hannes >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot From nobody Wed Dec 10 04:52:57 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC1F1A88B7 for ; Wed, 10 Dec 2014 04:52:55 -0800 (PST) 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 IgSk-Frb6Q68 for ; Wed, 10 Dec 2014 04:52:54 -0800 (PST) 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 2AFB11A1B65 for ; Wed, 10 Dec 2014 04:52:54 -0800 (PST) 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 sBACqmMO023571; Wed, 10 Dec 2014 13:52:48 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:d554:d7f3:a9f:662a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3jyJ8033gyz7tVH; Wed, 10 Dec 2014 13:52:48 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig In-Reply-To: <54875981.6060608@gmx.net> (Hannes Tschofenig's message of "Tue, 09 Dec 2014 21:20:17 +0100") References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Date: Wed, 10 Dec 2014 13:52:48 +0100 Message-ID: <878uifoee7.fsf@tzi.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/XgnPSPcbg6PVbuX79QCGkIkdZyY Cc: Kovatsch Matthias , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 10 Dec 2014 12:52:56 -0000 Hannes, Hannes Tschofenig writes: > On 12/09/2014 11:07 AM, Olaf Bergmann wrote: >> I presume that constrained devices will likely have static buffers with >> a fixed size. I do not see how they would dynamically adjust their size. > > It heavily depends on your implementation preferences on how to do the > memory management. No, not at all. Dynamic memory management not only requires some more resources (RAM and code) but also makes evaluation of runtime behavior very difficult for non-trivial applications. > Here is info about the memory model in mbed (see > http://developer.mbed.org/handbook/Memory-Model) and how dynamic memory > can be allocated. I fail to see how this generic overview gives any additional information that could be of use in this discussion? Regards Olaf From nobody Wed Dec 10 05:25:03 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A211A89ED for ; Wed, 10 Dec 2014 05:24:59 -0800 (PST) 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 4niPTOwfxjPs for ; Wed, 10 Dec 2014 05:24:57 -0800 (PST) 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 84F0C1A8988 for ; Wed, 10 Dec 2014 05:24:57 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MYtId-1YUIu51IDD-00VgRk; Wed, 10 Dec 2014 14:24:46 +0100 Message-ID: <5488499D.1050409@gmx.net> Date: Wed, 10 Dec 2014 14:24:45 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Olaf Bergmann References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> In-Reply-To: <878uifoee7.fsf@tzi.org> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jm5FbdGW8posor3CCfRjbTODqaSOqHFWi" X-Provags-ID: V03:K0:cMWg42hkLpy2LBEmQE++86dsLx9DKQeccMNKSmhpQDVOXg3P9MO qiQNfbSqH5dsPZtaeoDAb3VGqup/v6vnriB/J4/0Zq97LpOKkPKVqL3OQzK/dbypFehStXf M/he4lTmLCmZXsKeJMIS2OMMMpwIt1G7eeZVLNbhwasy4GyG0NKmZ5Qty+ELJ0KccxsQrAK PsoHNpTJ4WtxKof2qTM5A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/_LJliVFAsdGRonlXF9p1pBuSx70 Cc: Kovatsch Matthias , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 10 Dec 2014 13:25:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jm5FbdGW8posor3CCfRjbTODqaSOqHFWi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Olaf, On 12/10/2014 01:52 PM, Olaf Bergmann wrote: > Hannes, >=20 > Hannes Tschofenig writes: >=20 >> On 12/09/2014 11:07 AM, Olaf Bergmann wrote: >>> I presume that constrained devices will likely have static buffers wi= th >>> a fixed size. I do not see how they would dynamically adjust their si= ze. >> >> It heavily depends on your implementation preferences on how to do the= >> memory management. >=20 > No, not at all. Dynamic memory management not only requires some more > resources (RAM and code) but also makes evaluation of runtime behavior > very difficult for non-trivial applications. What kind of runtime behavior analysis are you thinking about? >=20 >> Here is info about the memory model in mbed (see >> http://developer.mbed.org/handbook/Memory-Model) and how dynamic memor= y >> can be allocated. >=20 > I fail to see how this generic overview gives any additional informatio= n > that could be of use in this discussion? This is just one example of a system that offers dynamic memory allocation for the application developer. As such, you cannot assume that all systems use static buffer allocation for IoT applications. Ciao Hannes >=20 > Regards > Olaf >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --jm5FbdGW8posor3CCfRjbTODqaSOqHFWi 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 iQEcBAEBCgAGBQJUiEmdAAoJEGhJURNOOiAtkVIH/3qIqQJGdvN/f4uxVEzRtUWl bcRFKNk20ZJqE+Mhiz6AFGkFAZ4ptqDcLo29XIVnweKloWsM1e3pVFZOl1imyAy4 58+GR5WtaHQBuUb18J3YABqrtIiA5q9RojtKt2pDWHMeafkLQGVBf07ATxljY/0B y1uAvY+EOLOTIDW7ADl6Th3ZrRvchi5OzCJUOQuAWlyRlnJHg5n8z3doxDueYuLh uwfGoGA03nkaEmZdRJLzm9Up+MYcyEq2XQKrnEIhQTBz86hJwIvgGrmEICaDtgvk R9CMPIowB8jyAqov2XyuIPEwaXzuGSjpiLnWKt3674xYU/T465eGdaqaJeWAnxQ= =0x6p -----END PGP SIGNATURE----- --jm5FbdGW8posor3CCfRjbTODqaSOqHFWi-- From nobody Wed Dec 10 05:27:26 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3441A0211 for ; Wed, 10 Dec 2014 05:27:22 -0800 (PST) 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 lAFVLKDhyTFS for ; Wed, 10 Dec 2014 05:27:20 -0800 (PST) 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 8F2E11A3B9C for ; Wed, 10 Dec 2014 05:27:20 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LbR3e-1XWoKC0vus-00kvDA; Wed, 10 Dec 2014 14:27:18 +0100 Message-ID: <54884A35.1010000@gmx.net> Date: Wed, 10 Dec 2014 14:27:17 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kovatsch Matthias , "dtls-iot@ietf.org" References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CAlT8FWRH8kNmd5xv67JtJgJ50R0cWaXe" X-Provags-ID: V03:K0:ihs2TkbIWp3f4Z/EiFURJnpcpwfS3s/uIs8b8WLnihl4j7RWjzs ryGE2ModuoE6pLSrs5RYMLtXFUdavvpQVlNyhjqfOPTON11dwBwh5GZMALeH7kSVF5n233v tPGGiNSJ/aPAPk+THIZJQTIr6JJcsxASUens6Tm0jhJDSIYO+mbbSDSxR/Qcyyv6Ff0o3jc ejrkIJVaSazGvLKPIeisA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/0CWst1Ocq6Hrx4NtDAthSydpVkk Subject: Re: [Dtls-iot] DTLS fragmentation 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, 10 Dec 2014 13:27:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CAlT8FWRH8kNmd5xv67JtJgJ50R0cWaXe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Matthias, I now want to respond to your initial question: On 12/07/2014 07:22 PM, Kovatsch Matthias wrote: > I have been wondering if the DTLS Profile should constrain the > fragmentation mechanism of DTLS. It is somewhat "chaotic," as it > allows fragments of different size that can also overlap. This can be > quite a burden for constrained devices. Shouldn't the DTLS Profile > maybe simplify this for DICE? I am aware that this will then also > affect the cloud side. I re-read the spec with this regard and I ran into this paragraph: " When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message. DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes. " I fear that we can not change this functionality in the profile document.= Ciao Hannes --CAlT8FWRH8kNmd5xv67JtJgJ50R0cWaXe 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 iQEcBAEBCgAGBQJUiEo1AAoJEGhJURNOOiAt5zkIAIbCb5CUurujcTohUOOWZFX0 7Ics/rkRMVU+3AOVdKjr2rVPjQT7gJmWkHl2p6kvLXRObI2YZaFtGdRlgSZBJODK cIMS3KoAf2oP0ErHBXOHRPql4kRMv168CpE6mHrHXZjdToB2F6O+0SO8Z4LelAB/ 9STnAlSUZri+N1LCBir18/Fy0kGXGrU5fhKHqHYvPEsBg42e4f3cDL6KJ4EzrIC3 cQ9TLQIY9PFtEutdqg83TfyMMW2j0d5RutKMC2AtA0V8k2jGniOekHQFN1dW/hQY oJIbOA+Zri96Ob0wc4iktBkEBr9HI2XW+CKnXUU0IAsV0DZpiBr2OfxdmiE1huE= =coeb -----END PGP SIGNATURE----- --CAlT8FWRH8kNmd5xv67JtJgJ50R0cWaXe-- From nobody Wed Dec 10 05:31:33 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25C01A89B9 for ; Wed, 10 Dec 2014 05:31:27 -0800 (PST) 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 zyy9hb4kTqYO for ; Wed, 10 Dec 2014 05:31:27 -0800 (PST) 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 CA3931A89AE for ; Wed, 10 Dec 2014 05:31:26 -0800 (PST) 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 sBADVLse026572; Wed, 10 Dec 2014 14:31:21 +0100 (CET) Received: from aung.tzi.org (dynamic-218-7.informatik.uni-bremen.de [134.102.218.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3jyK0T3f6Kz7vWC; Wed, 10 Dec 2014 14:31:21 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> Date: Wed, 10 Dec 2014 14:31:21 +0100 In-Reply-To: <5488499D.1050409@gmx.net> (Hannes Tschofenig's message of "Wed, 10 Dec 2014 14:24:45 +0100") Message-ID: <87oarbmy1i.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/daqLDNfWkZGupCH3mdVnybcp_eg Cc: Kovatsch Matthias , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 10 Dec 2014 13:31:28 -0000 Hannes Tschofenig writes: > Hi Olaf, > What kind of runtime behavior analysis are you thinking about? Depends on your implementation. Typical algorithms need to trade between internal and external fragementation. >> >>> Here is info about the memory model in mbed (see >>> http://developer.mbed.org/handbook/Memory-Model) and how dynamic memory >>> can be allocated. >> >> I fail to see how this generic overview gives any additional information >> that could be of use in this discussion? > This is just one example of a system that offers dynamic memory > allocation for the application developer. As such, you cannot assume > that all systems use static buffer allocation for IoT applications. Yes, it is an existence proof but not more. There is no doubt that malloc/new are available for many embedded OS. The question is whether or not one wants to use it. Regards Olaf From nobody Wed Dec 10 09:35:50 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5343A1A8763 for ; Wed, 10 Dec 2014 09:35:49 -0800 (PST) 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 Ri48Pf77pBlg for ; Wed, 10 Dec 2014 09:35:47 -0800 (PST) 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 050D61A87D2 for ; Wed, 10 Dec 2014 09:35:41 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MD9q8-1YAumg0wYO-00GYaB; Wed, 10 Dec 2014 18:35:34 +0100 Message-ID: <54888465.6020306@gmx.net> Date: Wed, 10 Dec 2014 18:35:33 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Alexey Melnikov References: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> <5478657E.4030106@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="416VNvoosLoKWm2aWOADMiNQA030vVnW6" X-Provags-ID: V03:K0:q++jpYUb0bwqbQ3zF5HfsqpIfpQmU+uf3vQXCP8ujkhVVu+ASok WFGu0LZjXBeqU0wRoqpKEFjMBIpoiazTf3a2vUfA6pZXPjN2BWY5mdougkOujv682n1LZwG FkPghq+rZqg1CafaPUVrl4/IlcbLAS6Xrq3pGFbH5kAZNs4cCR6RPEgr/osDAHnnSTkqcZn jtqivjmR5OxRvzMAU0FMw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/caBMLBDpQ2Ra2rtffPBiywLIPz0 Cc: Dorothy Gellert , Zach Shelby , "FOSSATI, Thomas \(Thomas\)" , "dtls-iot@ietf.org" Subject: [Dtls-iot] Downgrade-SCSV ... was Re: WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 10 Dec 2014 17:35:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --416VNvoosLoKWm2aWOADMiNQA030vVnW6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A few remarks in addition to what Thomas said below. The problem is trying to solve is that implementations do not rely only on the TLS implemented version negotiation mechanism. A further assumption is that the end points are running such an insecure version of TLS, for example, because they need to interact with some legacy systems. This allows an attacker to downgrade the protocol handshake to SSL 3.0 even if the protocol interaction in question could use something better. (Obviously with the legacy system nothing better than SSL 3.0 would work.) SSL 3.0 is so broken that there is no secure cipher available for it. If an attacker manages to downgrade the exchange to SSL 3.0 then he has essentially won. To apply this to the DTLS profile document is a bit tricky since we do not support versions older than DTLS 1.2. Of course, one could imagine a future where DTLS 1.2 a becomes so broken that it essentially has the quality of SSL 3.0. In that case I hope that the other recommendation for using the software update mechanism should kick-in. Finally, I doubt that IoT devices are less likely to support multiple versions of DTLS/TLS since this is also a size issue. In that sense it is rather difficult to downgrade to a different version. While the downgrade SCSV functionality is very lightweight (from an implementation point of view, as Manuel P=E9gouri=E9-Gonnard told me) it still does not make a lot of sense to me to support it. Ciao Hannes On 12/09/2014 04:08 PM, FOSSATI, Thomas (Thomas) wrote: > Hi Alexey, >=20 > On 28/11/2014 12:07, "Hannes Tschofenig" wr= ote: >> On 11/22/2014 08:08 PM, Alexey Melnikov wrote: >>> In Section 18: >>> >>> CoAP demands version 1.2 of DTLS to be used and the earlier versio= n >>> of DTLS is not supported. As such, there is no risk of downgradin= g >>> to an older version of DTLS. The work described in >>> [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable= to >>> this environment since there is no legacy server infrastructure to= >>> worry about. >>> >>> While I-D.bmoeller-tls-downgrade-scsv is not currently needed, it mig= ht >>> be useful when TLS 1.3/etc gets deployed and problems are found in TL= S >>> 1.2. Is this something we need to worry about in long term? >>> >> >> I created an issue for this item: >> https://tools.ietf.org/wg/dice/trac/ticket/21 >=20 > Do you think the following might be a sensible way out? >=20 > 1) We explicitly tell that the handshake MUST fail hard if a version < = 1.2 > is negotiated; > 2) once 1.3 is published, if 1.2 turns out to be flawed then deprecate = 1.2 > and jointly describe the use of SCSV to avoid 1.2 fallback. >=20 > Rationale: there seems to be no need for SCSV until 1.2 is shown to be > broken -- if we don't allow negotiating versions less then 1.2 in the > first place. >=20 >=20 > Cheers, t >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --416VNvoosLoKWm2aWOADMiNQA030vVnW6 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 iQEcBAEBCgAGBQJUiIRlAAoJEGhJURNOOiAtpFgH/26DT6CHOemhRoL7iH3yN7Qc GmCoo4kwYzNyadyZHNMq8dN1F3gwCijOXeDEYEw41rzx2LAo71zOT+oce/PsLAMw nt1kN0YHxtRu8J5sp+LlrbtjruoI/F/3UYszGgQK2feMhaobZgBOMFHOP29CDEjj G7rDPiEjpT42EeIhY02UMH5XXDGW/YU3Tbi8tEPiV+GV/6nEXnhP+anC60jpVelv LgjCtd5WjIJIBuUzZKLPkxpKe3qR8xDQwmS4AZhzEzWrGvqacTj210goYHCPAKzJ fv+XizwtSWSrNiWsUezgkL0o2jOaUMpMg9/mdl5knlQ+2aB/1bgV7p67ti4g8hQ= =xBL9 -----END PGP SIGNATURE----- --416VNvoosLoKWm2aWOADMiNQA030vVnW6-- From nobody Wed Dec 10 11:12:12 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828FC1A9044 for ; Wed, 10 Dec 2014 11:11:52 -0800 (PST) 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 e1-AMreLZ-ng for ; Wed, 10 Dec 2014 11:11:45 -0800 (PST) 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 4A6381A8AB5 for ; Wed, 10 Dec 2014 11:09:44 -0800 (PST) Received: from [192.168.131.136] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ltqmn-1XrKWn21f3-0116js; Wed, 10 Dec 2014 20:09:32 +0100 Message-ID: <54889A6B.9000906@gmx.net> Date: Wed, 10 Dec 2014 20:09:31 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Olaf Bergmann References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> <87oarbmy1i.fsf@tzi.org> In-Reply-To: <87oarbmy1i.fsf@tzi.org> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i19UiDiOQ3NQv8EDN6baQRArItT8Ngvtq" X-Provags-ID: V03:K0:5J1HX7McHevRyQ6+qAuW7yLOZ3qXP/kCt0qXRToXsEoTDfowtdq qQKqXkWaHPWj7Ur7pLp0by+LJdFDWMjWqXRw1RctlFbdldkxBUQn/hbuwstLAyfc2ziYqRn zeJ2AsCQADHe9U4tS4RzUvGDoGzCYW5EL9acJoPzStXWeT0ADtKqQMTLkmceIfLnCn7vtSo x000aTxItI81jmC3Osq8w== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/udFfm3r-XzI5eoo07C4CBsdDoSk Cc: Kovatsch Matthias , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 10 Dec 2014 19:11:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i19UiDiOQ3NQv8EDN6baQRArItT8Ngvtq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Olaf, I guess we indeed got a bit side-tracked in our discussion. You asked the following question: " Furthermore, it would be good to have a general idea what fragment sizes to expect, so that the buffers can be reasonably dimensioned. " Unfortunately, I have difficulties answering that question since it depends on a number of aspects, such as * what type of credential is being used, * what key size is used, * how long the identifiers are, * how large the certificates are (if certificate-based authentication is used), * what extensions are implemented, etc. If someone has some specific examples that they find worthwhile to include then I will do it. I fear, however, that we cannot state the maximum buffer size in the document. Ciao Hannes On 12/10/2014 02:31 PM, Olaf Bergmann wrote: > Hannes Tschofenig writes: >=20 >> Hi Olaf, >> What kind of runtime behavior analysis are you thinking about? >=20 > Depends on your implementation. Typical algorithms need to trade betwee= n > internal and external fragementation. >=20 >>> >>>> Here is info about the memory model in mbed (see >>>> http://developer.mbed.org/handbook/Memory-Model) and how dynamic mem= ory >>>> can be allocated. >>> >>> I fail to see how this generic overview gives any additional informat= ion >>> that could be of use in this discussion? >> This is just one example of a system that offers dynamic memory >> allocation for the application developer. As such, you cannot assume >> that all systems use static buffer allocation for IoT applications. >=20 > Yes, it is an existence proof but not more. There is no doubt that > malloc/new are available for many embedded OS. The question is whether > or not one wants to use it. >=20 > Regards > Olaf >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --i19UiDiOQ3NQv8EDN6baQRArItT8Ngvtq 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 iQEcBAEBCgAGBQJUiJprAAoJEGhJURNOOiAtrmgH/0tz39GApBH9oSP3soEdRRff OwyFrGvuFq9kUhAbe33o7Dzjgl4NbRc9ujN+gplbBZSg+YwQZvOaEuupc+X/V59E DQCRkV72je7UDrNYRPQDydrrUJeNZt5hKA+MmGhUxuPGOfrE13PqD7CdhY0be2Ea tFdwqjeYN4rf5bklBFoIzU6lLQM6Cr2G0vZO4jLrkKCOn3OjaCuHvgY04t1aJ0fa NLme4ahuJPAIp8xWfZFC1K3RckqoKiA/OOVjklpZ682bwG/rzxQseymxuMidJ4Od gNyHcz/03kAqEl+7oSib0lBKu9gR2kq6QdzYHA1Fd/CltBX1vvi0p4/D8mzL8tc= =wot3 -----END PGP SIGNATURE----- --i19UiDiOQ3NQv8EDN6baQRArItT8Ngvtq-- From nobody Wed Dec 10 14:28:04 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E808A1ABD35 for ; Wed, 10 Dec 2014 14:28:00 -0800 (PST) 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 Wu7tC5715aUX for ; Wed, 10 Dec 2014 14:27:59 -0800 (PST) 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 6CDB81ABC0F for ; Wed, 10 Dec 2014 14:27:59 -0800 (PST) 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 sBAMRtI1008859; Wed, 10 Dec 2014 23:27:55 +0100 (CET) Received: from [IPv6:2002:5489:10b9::816:102:8bc4:5530] (unknown [IPv6:2002:5489:10b9:0:816:102:8bc4:5530]) (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 3jyXvb1f7lz7tyN; Wed, 10 Dec 2014 23:27:55 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: <54888465.6020306@gmx.net> Date: Wed, 10 Dec 2014 23:27:54 +0100 X-Mao-Original-Outgoing-Id: 439943272.141867-76eeabcdc9edc7d52660f4e3a3329b08 Content-Transfer-Encoding: quoted-printable Message-Id: <788650B7-3264-4847-B673-AFF89215E2D9@tzi.org> References: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> <5478657E.4030106@gmx.net> <54888465.6020306@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/IljopWFe_Q-xsRkCTO_sK56g1Co Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Downgrade-SCSV ... was Re: WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 10 Dec 2014 22:28:01 -0000 On 10 Dec 2014, at 18:35, Hannes Tschofenig = wrote: >=20 > While the downgrade SCSV functionality is very lightweight (from an > implementation point of view, as Manuel P=E9gouri=E9-Gonnard told me) = it > still does not make a lot of sense to me to support it. It may be worth pointing out that the reason we haven=92t specified SCSV = support in is that we do not expect implementations of this profile to = support a broken version fallback mechanism, i.e. all version = negotiation MUST be using TLS mechanisms (as opposed to the ad-hoc hacks = that lead to SSLv3). Gr=FC=DFe, Carsten From nobody Wed Dec 10 14:49:24 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294DC1AC3F7 for ; Wed, 10 Dec 2014 14:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujtw8bLGWQ9o for ; Wed, 10 Dec 2014 14:49:20 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan28.extendcp.co.uk [176.32.228.2]) (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 81CC11AC3F3 for ; Wed, 10 Dec 2014 14:49:20 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Xyq4I-0007Fu-U0; Wed, 10 Dec 2014 22:49:14 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Xyq4I-0007VP-GX; Wed, 10 Dec 2014 22:49:15 +0000 Received: from host86-167-76-190.range86-167.btcentralplus.com ([86.167.76.190] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1Xyq4G-0001ux-UZ; Wed, 10 Dec 2014 22:49:13 +0000 Message-ID: <5488CDE3.6040507@gridmerge.com> Date: Wed, 10 Dec 2014 22:49:07 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Olaf Bergmann , Hannes Tschofenig References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> <87oarbmy1i.fsf@tzi.org> In-Reply-To: <87oarbmy1i.fsf@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050900080005060908050609" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/LAE-NK3OMUhs4ZmV8NejAONwo0k Cc: Kovatsch Matthias , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 22:49:23 -0000 This is a cryptographically signed message in MIME format. --------------ms050900080005060908050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Firstly, regarding memory allocation in embedded systems. There are many = ways of implementing memory allocation "dynamically" which doesn't mean=20 using the heap (malloc()/free() or new/delete). For stacks, buffer pools = are often used for packets/datagrams, which can be efficiently allocated = and freed. Therefore, I personally don't think it figures particularly=20 in the discussion. Regarding the two issues originally raised i.e. fragmentation and number = of handshake messages per flight: it is all about the MTU. If the MTU is = 1280, for example, it is likely in many cases DTLS fragmentation will=20 not be needed and furthermore it is likely that each flight will be able = to be contained in a single UDP datagram. This would very likely be the=20 case for PSK and RPK cipher suites (although I confess I haven't done=20 the actual numbers yet). It is probably only the cipher suites where=20 certificates are being sent back and forth that would cause=20 fragmentation in the 1280 MTU case. As already mentioned by Hannes, the=20 DTLS handshake record has to be reassembled in its entirety for the=20 verify_data calculations so space has to be allocated for it, so the=20 certificate-based cipher suites are again going to require the largest=20 amount of buffering and/or storage. If the MTU is much smaller, the two=20 issues Matthias originally mentioned will indeed come into play and it=20 may well be worth exploring what MTUs are available in which=20 implementations. The SMS case, for example, seems particularly=20 challenging, however small MTU sizes will be challenging for the=20 application layer as well, of course. Robert On 10/12/2014 13:31, Olaf Bergmann wrote: > Hannes Tschofenig writes: > >> Hi Olaf, >> What kind of runtime behavior analysis are you thinking about? > Depends on your implementation. Typical algorithms need to trade betwee= n > internal and external fragementation. > >>>> Here is info about the memory model in mbed (see >>>> http://developer.mbed.org/handbook/Memory-Model) and how dynamic mem= ory >>>> can be allocated. >>> I fail to see how this generic overview gives any additional informat= ion >>> that could be of use in this discussion? >> This is just one example of a system that offers dynamic memory >> allocation for the application developer. As such, you cannot assume >> that all systems use static buffer allocation for IoT applications. > Yes, it is an existence proof but not more. There is no doubt that > malloc/new are available for many embedded OS. The question is whether > or not one wants to use it. > > Regards > Olaf > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot > --------------ms050900080005060908050609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDEyMTAyMjQ5MDdaMCMGCSqGSIb3DQEJBDEWBBTISNI0tqcKYcYhuACvgsVcvXp60TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQAO37nGs1orKAzbasEKk8oFw2N7MnnBUPGK HUA09quZfDqlEUd5pQEQHDmaY/kbn1DLQKbNxrldNRddvisNnLQDR/FyFpYnBTYt4QywBcUq FMK4eo+aNxnIF1JCD9FPjzwdeKiMY5ifLlkg6KMR/7UdGdFZ6mDnQZ8Gvb2Ki9fT6+HpLOTs xZBFhQLVXutJsNNKXxw0MQE7Pt4itoAQ57uFgwM2gNadaI6tADxksqFzH9FjI0tdGdv+R7OZ YSM59YeGYfGms0qK6xHxVRK1igw8994US1NjJ2mQJDtc/rC6Ik9U8Db6MiAtiHiebZskOU4b GIY4S1ldoSCIof63OukWAAAAAAAA --------------ms050900080005060908050609-- From nobody Thu Dec 11 06:29:12 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FBB1ACE74 for ; Thu, 11 Dec 2014 06:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XRt44ONCpGrd for ; Thu, 11 Dec 2014 06:28:58 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1F31ACED5 for ; Thu, 11 Dec 2014 06:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418308137; d=isode.com; s=selector; i=@isode.com; bh=0k+UfDCDmG/XexEl3GvZnWcRpG1mXTPaWqL7B9HlSNc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kHMoUxyhZ1yJC93/aio9qBLLuxon0zb8u0MvC7oa8DrQIneRk9AaqWqRO+gLEVqsCjFFG9 WlFtFoQ0V6bn8pOlOZ9BSCEgJtv9wwHOQSd15vMvt/rnYzVvpo+sZk8mbHhUYpYSjB4Uia OKT3PBS+Rd2TrtOHNiNWxeVwBtxnQiM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 11 Dec 2014 14:28:57 +0000 Message-ID: <5489AA1C.9020805@isode.com> Date: Thu, 11 Dec 2014 14:28:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Hannes Tschofenig References: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> <5478657E.4030106@gmx.net> <54888465.6020306@gmx.net> In-Reply-To: <54888465.6020306@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Jl5-l1T656dFO4BR1nMzQWwT-Ps Cc: Dorothy Gellert , Zach Shelby , "FOSSATI, Thomas \(Thomas\)" , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Downgrade-SCSV ... was Re: WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 11 Dec 2014 14:29:01 -0000 On 10/12/2014 17:35, Hannes Tschofenig wrote: > A few remarks in addition to what Thomas said below. > > The problem is trying to solve is > that implementations do not rely only on the TLS implemented version > negotiation mechanism. > > A further assumption is that the end points are running such an insecure > version of TLS, for example, because they need to interact with some > legacy systems. > > This allows an attacker to downgrade the protocol handshake to SSL 3.0 > even if the protocol interaction in question could use something better. > (Obviously with the legacy system nothing better than SSL 3.0 would > work.) SSL 3.0 is so broken that there is no secure cipher available for > it. If an attacker manages to downgrade the exchange to SSL 3.0 then he > has essentially won. > > To apply this to the DTLS profile document is a bit tricky since we do > not support versions older than DTLS 1.2. Of course, one could imagine a > future where DTLS 1.2 a becomes so broken that it essentially has the > quality of SSL 3.0. Yes, that is the case I am concerned about. IoT devices once installed=20 might be working for years. > In that case I hope that the other recommendation > for using the software update mechanism should kick-in. Is this even likely? > Finally, I doubt that IoT devices are less likely to support multiple > versions of DTLS/TLS since this is also a size issue. In that sense it > is rather difficult to downgrade to a different version. > > While the downgrade SCSV functionality is very lightweight (from an > implementation point of view, as Manuel P=E9gouri=E9-Gonnard told me) it > still does not make a lot of sense to me to support it. I think I can buy your argument, but I suggest you add something like=20 your explanation above (at least setting expectations right) to the=20 document. > Ciao > Hannes > > On 12/09/2014 04:08 PM, FOSSATI, Thomas (Thomas) wrote: >> Hi Alexey, >> >> On 28/11/2014 12:07, "Hannes Tschofenig" wrot= e: >>> On 11/22/2014 08:08 PM, Alexey Melnikov wrote: >>>> In Section 18: >>>> >>>> CoAP demands version 1.2 of DTLS to be used and the earlier version >>>> of DTLS is not supported. As such, there is no risk of downgrading >>>> to an older version of DTLS. The work described in >>>> [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable = to >>>> this environment since there is no legacy server infrastructure to >>>> worry about. >>>> >>>> While I-D.bmoeller-tls-downgrade-scsv is not currently needed, it might >>>> be useful when TLS 1.3/etc gets deployed and problems are found in TLS >>>> 1.2. Is this something we need to worry about in long term? >>>> >>> I created an issue for this item: >>> https://tools.ietf.org/wg/dice/trac/ticket/21 >> Do you think the following might be a sensible way out? >> >> 1) We explicitly tell that the handshake MUST fail hard if a version < 1.= 2 >> is negotiated; >> 2) once 1.3 is published, if 1.2 turns out to be flawed then deprecate 1.= 2 >> and jointly describe the use of SCSV to avoid 1.2 fallback. >> >> Rationale: there seems to be no need for SCSV until 1.2 is shown to be >> broken -- if we don't allow negotiating versions less then 1.2 in the >> first place. >> >> >> Cheers, t >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >> From nobody Thu Dec 11 06:38:40 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251701ACEE4 for ; Thu, 11 Dec 2014 06:38:39 -0800 (PST) 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 1Ne8iMqQKWLs for ; Thu, 11 Dec 2014 06:38:38 -0800 (PST) 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 BDFB91ACEE3 for ; Thu, 11 Dec 2014 06:38:37 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0McmFl-1YGTHM2aRt-00HxRO; Thu, 11 Dec 2014 15:38:33 +0100 Message-ID: <5489AC69.2040703@gmx.net> Date: Thu, 11 Dec 2014 15:38:33 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Alexey Melnikov References: <6F73BAEE-5FA3-4BCA-9A28-B98E1093CB95@gmail.com> <5478657E.4030106@gmx.net> <54888465.6020306@gmx.net> <5489AA1C.9020805@isode.com> In-Reply-To: <5489AA1C.9020805@isode.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hbpeBQ0GnL6skVRO7G3RwejkJnrs44Mdg" X-Provags-ID: V03:K0:niD3Dh79Nfv6WFPklumMWnNKeb6JIO6BPia6A2wUYh1OPo2uf8P bFUb0zXfYHxQCrsL4Y55TI3/xPvQkQCoCjkRoBtY6XKMIC4yOipEKTmBh9EbdX8dwmFKQvp oQ21F/dOVW2BURTNxGy1Yil4Khr1r5IjvY13H+2EB68fZ+a2t8NAko2ldQjzP5Df6BhYED5 9XTpk7ZqJDQayu2TDLmEQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/YYekjIRW0nJ8HCv3EJRWTY9wkic Cc: Dorothy Gellert , Zach Shelby , "FOSSATI, Thomas \(Thomas\)" , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Downgrade-SCSV ... was Re: WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014 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, 11 Dec 2014 14:38:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hbpeBQ0GnL6skVRO7G3RwejkJnrs44Mdg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree that it is useful to add some text, as Carsten also noted, to help others to also understand our thought process. On 12/11/2014 03:28 PM, Alexey Melnikov wrote: > I think I can buy your argument, but I suggest you add something like > your explanation above (at least setting expectations right) to the > document. --hbpeBQ0GnL6skVRO7G3RwejkJnrs44Mdg 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 iQEcBAEBCgAGBQJUiaxpAAoJEGhJURNOOiAtYHEH/i6XfgQHu2dVcrgsOZSflJWT l04iGAqWwTAFuwqWf081IHIUX1cLwdZqp/IDivT9DGLKrK6RQxuORRpNebY6ZT3E oazkpp9h3Thgr2jO0SIXkcTtlQRNQ9K7rNoyg3/kZV0W8Xyr4rsp6Ecgr4ZPxPuS ogdOtWsGHZMs7CDLH/rF4S9Vlh+b7MwnyT2l6El3yC4jOv/HX1zwNupi1pGeEHye 7FhP1z1xugAl7Y5aZd9W/PayYzFAYoVoAGC/6tDGyFy53sxtnMf8aXWgVNWGXTv/ JxjSeFEO2jtL+rjcMc6hKZ0wHzNQEqY5igV+PxGK9pepdIMpqlzNhR6IZ40IpE8= =U/UP -----END PGP SIGNATURE----- --hbpeBQ0GnL6skVRO7G3RwejkJnrs44Mdg-- From nobody Thu Dec 11 07:03:04 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5B71ACEFF for ; Thu, 11 Dec 2014 07:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 JcDM0yxEjnBX for ; Thu, 11 Dec 2014 07:03:00 -0800 (PST) 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 2B8061ACF5B for ; Thu, 11 Dec 2014 07:02:43 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MDymt-1YBQ0V1nV1-00HNdh; Thu, 11 Dec 2014 16:02:40 +0100 Message-ID: <5489B20E.6070900@gmx.net> Date: Thu, 11 Dec 2014 16:02:38 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, Olaf Bergmann References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> <87oarbmy1i.fsf@tzi.org> <5488CDE3.6040507@gridmerge.com> In-Reply-To: <5488CDE3.6040507@gridmerge.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PH5R4M0Adkf8Rx72dvjT8jSTshEMc4vRR" X-Provags-ID: V03:K0:5sIcwhYSjRkJfgUwKGNP/CeAj0pIwnmPjPMh67N8PkVvL/B4SxD +2AgZnynj120eHhrRwXNcPxJWz0haAlHVRPnx3xcMkowtyBMFW1eBmCrJkSvt+ZlY1soVCp zXjnY2w+L5JOq5FQ3T5qnvJ3TODgs2nogD5dSQsZ2LCH5PIH6qaA/lDQEa203YLNO75bZSw 96syT6mMdhIiWkNz4S8aQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/mB0B7x36sXXnJl_Z9OUWMcexaXw Cc: Kovatsch Matthias , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation 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, 11 Dec 2014 15:03:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PH5R4M0Adkf8Rx72dvjT8jSTshEMc4vRR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess I agree with your observations about the memory management. The issues raised by Matthias and Olaf regarding fragmentation are good but it is just the question what we should do about them. Here are a few things we could do: a) provide examples of exchanges, including their message size. [I personally would prefer to put them into the LWIG TLS document instead= =2E] b) provide buffer size recommendations [While useful I don't have any suggestion what to write.] c) clarifications regarding the terminology (e.g., flight, DTLS message, fragment, datagram) [Maybe it is useful to provide a few examples of how messages could look like.] d) recommendations that change the DTLS/TLS spec with respect to the overlapping fragments [We cannot really do that as part of this work (even though I do not like the idea of overlapping fragments either.] Ciao Hannes On 12/10/2014 11:49 PM, Robert Cragie wrote: > Firstly, regarding memory allocation in embedded systems. There are man= y > ways of implementing memory allocation "dynamically" which doesn't mean= > using the heap (malloc()/free() or new/delete). For stacks, buffer pool= s > are often used for packets/datagrams, which can be efficiently allocate= d > and freed. Therefore, I personally don't think it figures particularly > in the discussion. >=20 > Regarding the two issues originally raised i.e. fragmentation and numbe= r > of handshake messages per flight: it is all about the MTU. If the MTU i= s > 1280, for example, it is likely in many cases DTLS fragmentation will > not be needed and furthermore it is likely that each flight will be abl= e > to be contained in a single UDP datagram. This would very likely be the= > case for PSK and RPK cipher suites (although I confess I haven't done > the actual numbers yet). It is probably only the cipher suites where > certificates are being sent back and forth that would cause > fragmentation in the 1280 MTU case. As already mentioned by Hannes, the= > DTLS handshake record has to be reassembled in its entirety for the > verify_data calculations so space has to be allocated for it, so the > certificate-based cipher suites are again going to require the largest > amount of buffering and/or storage. If the MTU is much smaller, the two= > issues Matthias originally mentioned will indeed come into play and it > may well be worth exploring what MTUs are available in which > implementations. The SMS case, for example, seems particularly > challenging, however small MTU sizes will be challenging for the > application layer as well, of course. >=20 > Robert >=20 >=20 > On 10/12/2014 13:31, Olaf Bergmann wrote: >> Hannes Tschofenig writes: >> >>> Hi Olaf, >>> What kind of runtime behavior analysis are you thinking about? >> Depends on your implementation. Typical algorithms need to trade betwe= en >> internal and external fragementation. >> >>>>> Here is info about the memory model in mbed (see >>>>> http://developer.mbed.org/handbook/Memory-Model) and how dynamic >>>>> memory >>>>> can be allocated. >>>> I fail to see how this generic overview gives any additional >>>> information >>>> that could be of use in this discussion? >>> This is just one example of a system that offers dynamic memory >>> allocation for the application developer. As such, you cannot assume >>> that all systems use static buffer allocation for IoT applications. >> Yes, it is an existence proof but not more. There is no doubt that >> malloc/new are available for many embedded OS. The question is whether= >> or not one wants to use it. >> >> Regards >> Olaf >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >> >=20 >=20 >=20 >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --PH5R4M0Adkf8Rx72dvjT8jSTshEMc4vRR 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 iQEcBAEBCgAGBQJUibIOAAoJEGhJURNOOiAtVBoIAIKys7ytw6AJ80DfRqpfNAEO fKbmp9D5vk726nfyAqz1htrlyRC/hxikdI3DNhcbxWvdpo+KD8RcuuslFsM93bqP 69VGHcjtbaYSYxrDYnG2kAbUvs3tPWDpYstm7s879Ed8dfDuCUgBahA4vvkBjD5x s4L+EBn95tUpBkb3hz9KOPAX8bQE8jiKYD+ejKSky6T6HtWJcqd2TTMxZqnqB8kW 2K9A2vnJtn28212lWpSsu7sixKAmwd+nrx+mgairBCRVUW023veQmFzKUyemkMve Ffth+P+JKCTftYEdGknT1UhPTnZtgTHZFrl58Cm5aQNeyjt4LvNOg3j02/ZMNd4= =YLkj -----END PGP SIGNATURE----- --PH5R4M0Adkf8Rx72dvjT8jSTshEMc4vRR-- From nobody Thu Dec 11 08:45:37 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70951A6FEF for ; Thu, 11 Dec 2014 08:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLBrWywVPpdz for ; Thu, 11 Dec 2014 08:45:32 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan41.extendcp.co.uk [176.32.230.35]) (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 BE40C1A1AF6 for ; Thu, 11 Dec 2014 08:45:31 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Xz6rk-00038p-LC; Thu, 11 Dec 2014 16:45:24 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Xz6rg-0003sJ-Sr; Thu, 11 Dec 2014 16:45:24 +0000 Received: from host86-167-76-190.range86-167.btcentralplus.com ([86.167.76.190] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1Xz6rf-0002sl-Km; Thu, 11 Dec 2014 16:45:20 +0000 Message-ID: <5489CA19.5040701@gridmerge.com> Date: Thu, 11 Dec 2014 16:45:13 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hannes Tschofenig , Olaf Bergmann References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> <87oarbmy1i.fsf@tzi.org> <5488CDE3.6040507@gridmerge.com> <5489B20E.6070900@gmx.net> In-Reply-To: <5489B20E.6070900@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050606030003010607050208" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/tt2F195QoCmFPsh6urY0x4qlZLM Cc: Kovatsch Matthias , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] DTLS fragmentation X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 16:45:35 -0000 This is a cryptographically signed message in MIME format. --------------ms050606030003010607050208 Content-Type: multipart/alternative; boundary="------------070408030701070709030702" This is a multi-part message in MIME format. --------------070408030701070709030702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, My suggestion was to look at typical MTUs used in constrained=20 environments, which is closest to (a), I guess. If the small MTU case is = mostly an edge case and the 1280-1500 MTU case is typical then I think=20 we can state that there should be no need for fragmentation unless it is = a certificate-based cipher suite and we can also recommend putting=20 multiple handshake messages in a single UDP datagram. If you think this=20 makes more sense for the LWIG document, we can put it there. I don't think (b) is going to be particularly useful in the profile=20 document. Again, it might make more sense to do this in the LWIG document= =2E (c) might help but there is an element of RTFM here - it is all in the=20 original specs. I do think examples would be good though. Perhaps pick=20 the three CoAP cipher suites and show what that might look like for=20 small and standard (i.e. 1280) MTU sizes. Regarding (d), the DTLS spec. already allows overlapping fragments. It=20 has to as it has to accommodate MTU resizing. Whilst it complicates=20 processing slightly, I don't think it is a major concern as the=20 handshake message needs to be reconstructed fully anyway. Robert On 11/12/2014 15:02, Hannes Tschofenig wrote: > I guess I agree with your observations about the memory management. > > The issues raised by Matthias and Olaf regarding fragmentation are good= > but it is just the question what we should do about them. > > Here are a few things we could do: > > a) provide examples of exchanges, including their message size. > [I personally would prefer to put them into the LWIG TLS document inste= ad.] > > b) provide buffer size recommendations > [While useful I don't have any suggestion what to write.] > > c) clarifications regarding the terminology (e.g., flight, DTLS message= , > fragment, datagram) > [Maybe it is useful to provide a few examples of how messages could loo= k > like.] > > d) recommendations that change the DTLS/TLS spec with respect to the > overlapping fragments > [We cannot really do that as part of this work (even though I do not > like the idea of overlapping fragments either.] > > Ciao > Hannes > > On 12/10/2014 11:49 PM, Robert Cragie wrote: >> Firstly, regarding memory allocation in embedded systems. There are ma= ny >> ways of implementing memory allocation "dynamically" which doesn't mea= n >> using the heap (malloc()/free() or new/delete). For stacks, buffer poo= ls >> are often used for packets/datagrams, which can be efficiently allocat= ed >> and freed. Therefore, I personally don't think it figures particularly= >> in the discussion. >> >> Regarding the two issues originally raised i.e. fragmentation and numb= er >> of handshake messages per flight: it is all about the MTU. If the MTU = is >> 1280, for example, it is likely in many cases DTLS fragmentation will >> not be needed and furthermore it is likely that each flight will be ab= le >> to be contained in a single UDP datagram. This would very likely be th= e >> case for PSK and RPK cipher suites (although I confess I haven't done >> the actual numbers yet). It is probably only the cipher suites where >> certificates are being sent back and forth that would cause >> fragmentation in the 1280 MTU case. As already mentioned by Hannes, th= e >> DTLS handshake record has to be reassembled in its entirety for the >> verify_data calculations so space has to be allocated for it, so the >> certificate-based cipher suites are again going to require the largest= >> amount of buffering and/or storage. If the MTU is much smaller, the tw= o >> issues Matthias originally mentioned will indeed come into play and it= >> may well be worth exploring what MTUs are available in which >> implementations. The SMS case, for example, seems particularly >> challenging, however small MTU sizes will be challenging for the >> application layer as well, of course. >> >> Robert >> >> >> On 10/12/2014 13:31, Olaf Bergmann wrote: >>> Hannes Tschofenig writes: >>> >>>> Hi Olaf, >>>> What kind of runtime behavior analysis are you thinking about? >>> Depends on your implementation. Typical algorithms need to trade betw= een >>> internal and external fragementation. >>> >>>>>> Here is info about the memory model in mbed (see >>>>>> http://developer.mbed.org/handbook/Memory-Model) and how dynamic >>>>>> memory >>>>>> can be allocated. >>>>> I fail to see how this generic overview gives any additional >>>>> information >>>>> that could be of use in this discussion? >>>> This is just one example of a system that offers dynamic memory >>>> allocation for the application developer. As such, you cannot assume= >>>> that all systems use static buffer allocation for IoT applications. >>> Yes, it is an existence proof but not more. There is no doubt that >>> malloc/new are available for many embedded OS. The question is whethe= r >>> or not one wants to use it. >>> >>> Regards >>> Olaf >>> >>> _______________________________________________ >>> dtls-iot mailing list >>> dtls-iot@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtls-iot >>> >> >> >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >> > > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot --------------070408030701070709030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hannes,

My suggestion was to look at typical MTUs used in constrained environments, which is closest to (a), I guess. If the small MTU case is mostly an edge case and the 1280-1500 MTU case is typical then I think we can state that there should be no need for fragmentation unless it is a certificate-based cipher suite and we can also recommend putting multiple handshake messages in a single UDP datagram. If you think this makes more sense for the LWIG document, we can put it there.

I don't think (b) is going to be particularly useful in the profile document. Again, it might make more sense to do this in the LWIG document.

(c) might help but there is an element of RTFM here - it is all in the original specs. I do think examples would be good though. Perhaps pick the three CoAP cipher suites and show what that might look like for small and standard (i.e. 1280) MTU sizes.

Regarding (d), the DTLS spec. already allows overlapping fragments. It has to as it has to accommodate MTU resizing. Whilst it complicates processing slightly, I don't think it is a major concern as the handshake message needs to be reconstructed fully anyway.

Robert

On 11/12/2014 15:02, Hannes Tschofenig= wrote:
I guess I agree with your observations about the mem=
ory management.

The issues raised by Matthias and Olaf regarding fragmentation are good
but it is just the question what we should do about them.

Here are a few things we could do:

a) provide examples of exchanges, including their message size.
[I personally would prefer to put them into the LWIG TLS document instead=
=2E]

b) provide buffer size recommendations
[While useful I don't have any suggestion what to write.]

c) clarifications regarding the terminology (e.g., flight, DTLS message,
fragment, datagram)
[Maybe it is useful to provide a few examples of how messages could look
like.]

d) recommendations that change the DTLS/TLS spec with respect to the
overlapping fragments
[We cannot really do that as part of this work (even though I do not
like the idea of overlapping fragments either.]

Ciao
Hannes

On 12/10/2014 11:49 PM, Robert Cragie wrote:

Firstly, regarding memory allocation in embedded s=
ystems. There are many
ways of implementing memory allocation "dynamically" which doesn't mean
using the heap (malloc()/free() or new/delete). For stacks, buffer pools
are often used for packets/datagrams, which can be efficiently allocated
and freed. Therefore, I personally don't think it figures particularly
in the discussion.

Regarding the two issues originally raised i.e. fragmentation and number
of handshake messages per flight: it is all about the MTU. If the MTU is
1280, for example, it is likely in many cases DTLS fragmentation will
not be needed and furthermore it is likely that each flight will be able
to be contained in a single UDP datagram. This would very likely be the
case for PSK and RPK cipher suites (although I confess I haven't done
the actual numbers yet). It is probably only the cipher suites where
certificates are being sent back and forth that would cause
fragmentation in the 1280 MTU case. As already mentioned by Hannes, the
DTLS handshake record has to be reassembled in its entirety for the
verify_data calculations so space has to be allocated for it, so the
certificate-based cipher suites are again going to require the largest
amount of buffering and/or storage. If the MTU is much smaller, the two
issues Matthias originally mentioned will indeed come into play and it
may well be worth exploring what MTUs are available in which
implementations. The SMS case, for example, seems particularly
challenging, however small MTU sizes will be challenging for the
application layer as well, of course.

Robert


On 10/12/2014 13:31, Olaf Bergmann wrote:

Hannes Tschofenig<hannes.tschofenig@gmx.n=
et>  writes:


Hi Olaf,
What kind of runtime behavior analysis are you thinking about?

Depends on your implementation. Typical algorith=
ms need to trade between
internal and external fragementation.


Here is info about the memory model in mbe=
d (see
http://developer.mbed.org/handbook/Memory-Model) a=
nd how dynamic
memory
can be allocated.

I fail to see how this generic overview give=
s any additional
information
that could be of use in this discussion?

This is just one example of a system that offe=
rs dynamic memory
allocation for the application developer. As such, you cannot assume
that all systems use static buffer allocation for IoT applications.

Yes, it is an existence proof but not more. Ther=
e is no doubt that
malloc/new are available for many embedded OS. The question is whether
or not one wants to use it.

Regards
Olaf

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





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



      

      

      

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


    

    

  


--------------070408030701070709030702--

--------------ms050606030003010607050208
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC
BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3
o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU
a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU
q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK
LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ
Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo
//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN
IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/
cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B
EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR
2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E
BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js
LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE
KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB
DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1
uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX
aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW
ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla
4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5
MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa
MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN
MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD
VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu
Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp
ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt
UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT
DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j
qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF
mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6
7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD
qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH
CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4
xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw
RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1
cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy
bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0
LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa
1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1
5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr
Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m
LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5
WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ
BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEyMTExNjQ1MTNaMCMGCSqGSIb3DQEJBDEWBBQ8+HDgVUeOuQLaDvWzxFMRT4xLPDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g
UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0
T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQB7gWsuBQLlgQAzAEg8fGM8XOxeM8JMdFJl
R+Tt9efMVQYNN2iMgpelOHDzTtDYBUj1hKJTstQq0dOeqKP0Hzs9RD4+CSArYqKrMkajFqa2
H6Q4OBmW8okAmGTqcR1a0uaX/o+QNW/cboI+2nrIOIAsU4xNn6dvK6tCjNz64D24i4q2KsS/
W82GDx34eUU2VZlg60LcMNw9xuh/OX8H5+FkhLhndUMEg3x1RynLGsWmYvCGKkSoXJKvMH1X
IlzYgKbTWc1uTt4it3N/FTtp+iW3RLIgaz+HeY76C3Do1Eb1SGZrLRSMWrufx5NO97qdi39n
yyWWRoUVuObk9d07RXLUAAAAAAAA
--------------ms050606030003010607050208--


From nobody Thu Dec 11 09:10:10 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0191A1AFE for ; Thu, 11 Dec 2014 09:10:00 -0800 (PST)
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 iwTBB6mcYusU for ; Thu, 11 Dec 2014 09:09:57 -0800 (PST)
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 296931A0141 for ; Thu, 11 Dec 2014 09:09:56 -0800 (PST)
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 sBBH9bRs025438; Thu, 11 Dec 2014 18:09:37 +0100 (CET)
Received: from aung.tzi.org (unknown [134.102.116.242]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3jz1ns0r07z7x01; Thu, 11 Dec 2014 18:09:37 +0100 (CET)
From: Olaf Bergmann 
To: Robert Cragie 
References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch>  <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> <87oarbmy1i.fsf@tzi.org> <5488CDE3.6040507@gridmerge.com>
Date: Thu, 11 Dec 2014 18:09:36 +0100
In-Reply-To: <5488CDE3.6040507@gridmerge.com> (Robert Cragie's message of "Wed, 10 Dec 2014 22:49:07 +0000")
Message-ID: <87bnnacdv3.fsf@tzi.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/2w0gyhpcZSXIhxE5ckSpw-Nsm4Y
Cc: Kovatsch Matthias , Hannes Tschofenig , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" 
Subject: Re: [Dtls-iot] DTLS fragmentation
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, 11 Dec 2014 17:10:00 -0000

Robert Cragie  writes:

> Firstly, regarding memory allocation in embedded systems. There are
> many ways of implementing memory allocation "dynamically" which
> doesn't mean using the heap (malloc()/free() or new/delete). For
> stacks, buffer pools are often used for packets/datagrams, which can
> be efficiently allocated and freed. Therefore, I personally don't
> think it figures particularly in the discussion.

Again: You are describing static memory management (a fixed number of
buffers in a pool, each with a fixed size).

If you want to review dynamic storage allocation techniques and their
implications, I can recommend reading Paul R. Wilson, Mark S. Johnstone,
Michael Neely, David Boles: Dynamic storage allocation: A survey and
critical review. In: Memory Management.  Lecture Notes in Computer
Science Volume 986, 1995, pp 1--116.

Regards
Olaf


From nobody Thu Dec 11 09:19:25 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E141A6FC8 for ; Thu, 11 Dec 2014 09:19:21 -0800 (PST)
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 ujHFHrbLCfr2 for ; Thu, 11 Dec 2014 09:19:21 -0800 (PST)
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 25B721A6FC2 for ; Thu, 11 Dec 2014 09:19:20 -0800 (PST)
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 sBBHJ2K5017550; Thu, 11 Dec 2014 18:19:02 +0100 (CET)
Received: from aung.tzi.org (unknown [134.102.116.242]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3jz20k4g6Dz7vwc; Thu, 11 Dec 2014 18:19:02 +0100 (CET)
From: Olaf Bergmann 
To: Hannes Tschofenig 
References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch>  <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> <87oarbmy1i.fsf@tzi.org> <5488CDE3.6040507@gridmerge.com> <5489B20E.6070900@gmx.net>
Date: Thu, 11 Dec 2014 18:19:02 +0100
In-Reply-To: <5489B20E.6070900@gmx.net> (Hannes Tschofenig's message of "Thu,  11 Dec 2014 16:02:38 +0100")
Message-ID: <8761dicdfd.fsf@tzi.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/ZhflpObmd5M1KreE6OFFP-OdbMk
Cc: Kovatsch Matthias , robert.cragie@gridmerge.com, Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" 
Subject: Re: [Dtls-iot] DTLS fragmentation
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, 11 Dec 2014 17:19:22 -0000

Hannes Tschofenig  writes:

> Here are a few things we could do:
>
> a) provide examples of exchanges, including their message size.
> [I personally would prefer to put them into the LWIG TLS document instead.]
>
> b) provide buffer size recommendations
> [While useful I don't have any suggestion what to write.]

I think (a) would be good to have (and yes, sounds more like the LWIG
TLS document). From (a), implementors might be able to infer (b), don't
they?

Regards
Olaf


From nobody Thu Dec 11 11:36:24 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7DB1A1A9A for ; Thu, 11 Dec 2014 11:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI9VDmUzsaZm for ; Thu, 11 Dec 2014 11:36:21 -0800 (PST)
Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.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 D093B1A1B57 for ; Thu, 11 Dec 2014 11:36:20 -0800 (PST)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g65.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Xz9X5-0004tc-OZ; Thu, 11 Dec 2014 19:36:15 +0000
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Xz9X2-00038z-T3; Thu, 11 Dec 2014 19:36:15 +0000
Received: from host86-167-76-190.range86-167.btcentralplus.com ([86.167.76.190] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1Xz9X1-0004TT-El; Thu, 11 Dec 2014 19:36:11 +0000
Message-ID: <5489F224.8080005@gridmerge.com>
Date: Thu, 11 Dec 2014 19:36:04 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Olaf Bergmann 
References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch>  <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net> <878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net> <87oarbmy1i.fsf@tzi.org> <5488CDE3.6040507@gridmerge.com> <87bnnacdv3.fsf@tzi.org>
In-Reply-To: <87bnnacdv3.fsf@tzi.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090705040007000701020901"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/iRfkkg0MOC2KRTHVeFonJQUEu2U
Cc: Kovatsch Matthias , Hannes Tschofenig , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" 
Subject: Re: [Dtls-iot] DTLS fragmentation
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: DTLS for IoT discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 19:36:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms090705040007000701020901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Well, it's a moot point whether it is static or dynamic, which is why I=20
put "dynamically" in quotes. "static" and "fixed" do not mean the same=20
thing.

Either way, I don't think it figures in the discussion.

Robert

On 11/12/2014 17:09, Olaf Bergmann wrote:
> Robert Cragie  writes:
>
>> Firstly, regarding memory allocation in embedded systems. There are
>> many ways of implementing memory allocation "dynamically" which
>> doesn't mean using the heap (malloc()/free() or new/delete). For
>> stacks, buffer pools are often used for packets/datagrams, which can
>> be efficiently allocated and freed. Therefore, I personally don't
>> think it figures particularly in the discussion.
> Again: You are describing static memory management (a fixed number of
> buffers in a pool, each with a fixed size).
>
> If you want to review dynamic storage allocation techniques and their
> implications, I can recommend reading Paul R. Wilson, Mark S. Johnstone=
,
> Michael Neely, David Boles: Dynamic storage allocation: A survey and
> critical review. In: Memory Management.  Lecture Notes in Computer
> Science Volume 986, 1995, pp 1--116.
>
> Regards
> Olaf
>
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot
>



--------------ms090705040007000701020901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC
BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3
o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU
a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU
q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK
LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ
Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo
//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN
IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/
cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B
EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR
2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E
BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js
LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE
KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB
DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1
uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX
aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW
ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla
4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5
MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa
MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN
MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD
VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu
Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp
ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt
UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT
DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j
qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF
mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6
7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD
qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH
CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4
xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw
RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1
cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy
bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0
LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa
1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1
5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr
Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m
LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5
WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ
BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNDEyMTExOTM2MDRaMCMGCSqGSIb3DQEJBDEWBBRNYxMsxNZs0OF7qvnZBhdBAFAK1TBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT
B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g
UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0
T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQCTAsmUpURtP9iIJXDKY90dvz/5D8p3oI+N
HV6wS5dUwUlyND/Lc3BLdcEc9D6gm2LuYTZacYBC5og6+tqLsfgGNwkpV4uFQ9Z+mznhRYzq
mfxEQzNXibaqAoQ+OXX/rrTRW5OaZhfZllTQ4OfdGfsxZFBDxLljQ13+H/zZu/qtd+EWHYAC
uNP4oE9LyLYMs3SmHQGYSwpTNtDWcj+3sMKHSjgnSLluN4SEQiEUUqQ0WrM89UMWsJoDE64U
u80wX83YJgk89w7AInEcughulXR4ntucRiNtha+Woww9Fd0rOB/R3t3XAkkXWfTD5gf3u8AQ
Uv9NJ/1EvCmYDHXvJgqiAAAAAAAA
--------------ms090705040007000701020901--


From nobody Fri Dec 12 02:33:12 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869461ACCE4 for ; Fri, 12 Dec 2014 02:33:11 -0800 (PST)
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 a05oha68or7S for ; Fri, 12 Dec 2014 02:33:09 -0800 (PST)
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 981ED1ACCDC for ; Fri, 12 Dec 2014 02:33:08 -0800 (PST)
Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lj1Cw-1XOOtA0zJ0-00dCbf for ; Fri, 12 Dec 2014 11:33:06 +0100
Message-ID: <548AC461.7080203@gmx.net>
Date: Fri, 12 Dec 2014 11:33:05 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.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="iabkbUOjcE6XDLLivIlmCQvecJeRqutdd"
X-Provags-ID: V03:K0:9dkGd90Fnn785JE8hNeN/q+zaUZsa0Yj1vYgOCY8PdTc0jYnazq srDvVrQk68kN7k8cYOfn4VC+piN/emUkMxNo70ck+WJ2NvEVn/BwUWl1DQIj+n0tYvACM/H A7U8IPp884ZpP7vzwvlV2uPy3iHQtYvHrvj4Dw+T6HlAGFhl5HtydhucoK76u8QGJ/Zadqz lT5LukU+i5UjgkFQLbCfw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/sFfOZ9VWmIEIlprPXA1jz_t6hfE
Subject: [Dtls-iot] Making progress on the constrained server topic
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, 12 Dec 2014 10:33:11 -0000

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

Hi all,

as I am preparing another draft update of the profile draft (see
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profi=
le/draft-ietf-dice-profile-07.txt)
I re-read the current write-up and thought about the necessary changes
to support a constrained server implementation, i.e., an IoT device that
runs a constrained server. It turns out that the changes on the surface
are actually fairly small. Here is the list of impacted sections.

Changes required:

 - Use Session Resumption without server-side state (rather than session
resumption) to push state information to clients.
 - Server Name Indication (SNI) since it is less likely to be used on a
constrained server.
 - Random Number Generation because of the reference to
[I-D.mathewson-no-gmtunixtime]. (small change).

No change:

 - Perfect Forward Secrecy
 - Keep-Alive
 - Timeouts
 - Truncated MAC and Encrypt-then-MAC Extension
 - Maximum Fragment Length Negotiation
 - Session Hash
 - Re-Negotiation Attacks
 - Downgrading Attacks
 - Crypto Agility
 - Key Length Recommendations
 - False Start

The challenges do, however, start when it comes to the assumptions
behind made by the current text. As the text is currently written, the
assumption is that there is a very close relationship between the
constrained client and the server (which is sitting somewhere in the
cloud). This is a quite realistic usage model since this is what we are
seeing today with many deployments where the device maker also provides
the corresponding server-side infrastructure.

This gives the vendor a lot of freedom with regard to the use of the
credentials and also to implement a software update mechanism the device
can use to deal with functionality like revocation and trust anchor
provisioning.

There is also no problem with discovery (since we assume that the
information about the server is pre-configured). There is also not
problem with reachability since the client starts the communication
exchange.

Now, as we move to a different design pattern, such as the
device-to-device communication model these assumptions suddenly do not
work anymore. It turns out that the differentiation between constrained
server vs. constrained client isn't all that relevant; what is relevant
is the relationship between the different devices and what information
can (or cannot) realistically assumed to be present.

Of course, there is no documentation of these different design patterns
(other than the brief write-up in
https://tools.ietf.org/html/draft-iab-smart-object-architecture-06).
There is no place I can point people that contains a detailed description=
=2E

In general, there will be the following problems to deal with:

 a) Discovery & Reachability

How does the client learn that it has to talk to a specific server?
How do the entity initiating the communication actually reach the other
end (and how does it maintain that connectivity)?

 b) Authentication

What credentials can be used to authenticate the two parties?

 c) Authorization

How are the two parties going to authorize each other? It is not just
about authorizing the client when it accesses a resource but also about
the client ensuring that it indeed talks to a legitimate server?

Does this sound familiar? I am sure it does. This is essentially the ACE
problem statement. In the current client-to-cloud model all these
problems are sort of "solved" by simply assuming that the cloud service
provider also provisions the IoT device. But in a more open model (which
is, quite naturally, important to have) these questions are then solved
either using pairing (in the very limited case, see description in
Section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00) or by
introducing this famous third party (which is the authorization server
in the ACE case).

What does this mean for the draft?

I can cheat a little bit by glancing over the hard problems and just
start with the assumption that the client will somehow get the right
credentials, configuration information, access rights, revocation
information, etc. from somewhere. Hence, this is a pure TLS exchange and
I only need to make the modifications stated at the beginning of my
mail. I could reference the ongoing ACE work, which will at least deal
with the authorization questions. Of course, that write-up in the DICE
draft by itself is not be interoperable as a standalone item.

How does that sound?

Ciao
Hannes





--iabkbUOjcE6XDLLivIlmCQvecJeRqutdd
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

iQEcBAEBCgAGBQJUisRiAAoJEGhJURNOOiAty8sH/is7Z86IszWhRwHGnAySfqFO
D1uToAkDCWtrIaUcYz/lTAq/cmUFaiyjKXlRBZa4WDpNMGyAiK4rMeesp1M5fYNQ
i60KZHlQX1jFE47V3Tz589oGdkUUqOStav2U/VxPyw/TcilzDSrebbPYPBRr9R+R
SQyoBAlFZ/wcThaBPdgMBQXJXfZenXdymtgK+MuP326zBn4rbXoLCGReqPsdHA3Q
+EMoEfRXe7VcfXLYP8acS6OXN3qSQSOEvsTpKinoKgyff5yqotn/TxpWU4hi4nD7
QVKtU5JwmNPou5XHu8AM//xGERXxf/A8vMlCy5baqMW6BDU2LBc39IjvhBQVjvg=
=cQOj
-----END PGP SIGNATURE-----

--iabkbUOjcE6XDLLivIlmCQvecJeRqutdd--


From nobody Fri Dec 12 10:54:01 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324391A8766 for ; Fri, 12 Dec 2014 10:53:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.245
X-Spam-Level: 
X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOy8B7fZrkvs for ; Fri, 12 Dec 2014 10:53:56 -0800 (PST)
Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774551AC432 for ; Fri, 12 Dec 2014 10:53:55 -0800 (PST)
X-ASG-Debug-ID: 1418410433-06daaa512562cd0001-roOjxa
Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id a1e2tpvXyX5RiuEd for ; Fri, 12 Dec 2014 13:53:53 -0500 (EST)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Dec 2014 13:53:52 -0500
Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Dec 2014 13:53:52 -0500
Received: from NISSONITE.InterDigital.com (10.2.64.252) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 12 Dec 2014 13:53:51 -0500
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 13:53:48 -0500
From: "Rahman, Akbar" 
To: Hannes Tschofenig , "dtls-iot@ietf.org" 
Thread-Topic: [Dtls-iot] Making progress on the constrained server topic
X-ASG-Orig-Subj: RE: [Dtls-iot] Making progress on the constrained server topic
Thread-Index: AQHQFfcKjxHA38OSMkWo7vTsCDVsGZyMRpZg
Date: Fri, 12 Dec 2014 18:53:47 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F08DCA1@NABESITE.InterDigital.com>
References: <548AC461.7080203@gmx.net>
In-Reply-To: <548AC461.7080203@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.15]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Dec 2014 18:53:52.0519 (UTC) FILETIME=[F9011170:01D0163C]
X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27]
X-Barracuda-Start-Time: 1418410433
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.12810 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/jFgUyia960C4ZH_8BXcxIhHpSYY
Subject: Re: [Dtls-iot] Making progress on the constrained server topic
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, 12 Dec 2014 18:53:58 -0000

SGkgSGFubmVzLA0KDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBjb250aW51ZWQgZWZm
b3J0IG9uIHRoaXMgdG9waWMuICBBcyB5b3Uga25vdywgSSBzdHJvbmdseSBzdXBwb3J0IGNvbnNp
ZGVyaW5nIHRoZSBjb25zdHJhaW5lZCBzZXJ2ZXIgY2FzZSBpbiB5b3VyIGRvY3VtZW50LiAgSSB3
b3VsZCBsaWtlIHRvIGdpdmUgZmVlZGJhY2sgb24gb25lIG9mIHRoZSBrZXkgcG9pbnRzIGZyb20g
eW91ciBkZXRhaWxlZCBhbmFseXNpczoNCg0KPmEpIERpc2NvdmVyeSAmIFJlYWNoYWJpbGl0eQ0K
Pg0KPkhvdyBkb2VzIHRoZSBjbGllbnQgbGVhcm4gdGhhdCBpdCBoYXMgdG8gdGFsayB0byBhIHNw
ZWNpZmljIHNlcnZlcj8NCg0KDQpJZiB3ZSBjb25zaWRlciBDb0FQIGFzIHRoZSBhcHBsaWNhdGlv
biBwcm90b2NvbCBiZWluZyBydW4gYmV0d2VlbiB0aGUgSW9UIGRldmljZSBhbmQgdGhlIGNvbnN0
cmFpbmVkIHNlcnZlciB0aGVuIHRoZSBhbnN3ZXIgaXMgY2xlYXIuICBEaXNjb3ZlcnkgKG9mIHJl
c291cmNlcyBhbmQvb3Igc2VydmVycykgaXMgZG9uZSBieSBzZW5kaW5nIGEgdW5pY2FzdCBvciBt
dWx0aWNhc3QgQ29BUCBHRVQgdG8gYSB3ZWxsLWtub3duIFVSSS4gIFZhcmlvdXMgYXNwZWN0cyBv
ZiB0aGlzIGRpc2NvdmVyeSBpcyBleHBsYWluZWQgaW4gbXVsdGlwbGUgUkZDcy9kcmFmdHM6DQoN
CjEpIFRoZSBDT1JFIExpbmsgZm9ybWF0IGRvY3VtZW50IFtSRkMgNjY5MF0gd2hpY2ggZmlyc3Qg
ZGVzY3JpYmVkIHRoZSB1c2UgY2FzZSwgYW5kIHJlc2VydmVkIHRoZSBVUkk6DQoJLSBVc2UgQ2Fz
ZTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjY5MCNzZWN0aW9uLTEuMi4xIA0KCS0g
UmVzZXJ2aW5nIHRoZSBVUkk6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY2OTAjc2Vj
dGlvbi03LjEgDQoNCjIpIFRoZSBDb0FQIHNwZWMgW1JGQyA3MjUyXSBhbHNvIHByb3ZpZGVzIGEg
bmljZSBzdW1tYXJ5IG9mIHRoZSBvcGVyYXRpb246DQoJLSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9yZmM3MjUyI3NlY3Rpb24tNyANCg0KMykgVGhlIENvQVAgR3JvdXAgQ29tbXVuaWNhdGlv
bnMgc3BlYyBbUkZDIDczOTBdIGdpdmVzIGEgZGV0YWlsZWQgdXNlIGNhc2Ugb24gaG93IHRvIG11
bHRpY2FzdCBkaXNjb3ZlciBDb0FQIHNlcnZlcnMsIGFuZCB0aGUgcHJvdG9jb2wgcHJvY2Vzc2lu
ZyBydWxlczoNCgktIFVzZSBDYXNlOiAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzM5
MCNzZWN0aW9uLTMuMyANCgktIFByb3RvY29sIHByb2Nlc3NpbmcgKHNlZSA1dGggc3ViLWJ1bGxl
dCkgOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MzkwI3NlY3Rpb24tMi43IA0KDQoN
ClNvLCBteSBvcGluaW9uIGlzIHRoYXQgdGhpcyBpc3N1ZSBpcyB3ZWxsIHNvbHZlZCBhdCBsZWFz
dCBmb3IgdGhlIENvQVAgY2FzZS4gIERvIHlvdSBhZ3JlPw0KDQoNCg0KPkhvdyBkbyB0aGUgZW50
aXR5IGluaXRpYXRpbmcgdGhlIGNvbW11bmljYXRpb24gYWN0dWFsbHkgcmVhY2ggdGhlIG90aGVy
IGVuZCAoYW5kIGhvdyBkb2VzIGl0IG1haW50YWluIHRoYXQgY29ubmVjdGl2aXR5KT8NCg0KSSB0
aGluayBDYXJzdGVuIHByZXZpb3VzbHkgZ2F2ZSBhIGdvb2QgYW5zd2VyIHRvIGEgc2ltaWxhciBx
dWVzdGlvbjoNCg0KCS0gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2R0bHMt
aW90L2N1cnJlbnQvbXNnMDA0NzQuaHRtbCANCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpBa2Jh
cg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGR0bHMtaW90IFttYWls
dG86ZHRscy1pb3QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2Zl
bmlnDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDEyLCAyMDE0IDU6MzMgQU0NClRvOiBkdGxzLWlv
dEBpZXRmLm9yZw0KU3ViamVjdDogW0R0bHMtaW90XSBNYWtpbmcgcHJvZ3Jlc3Mgb24gdGhlIGNv
bnN0cmFpbmVkIHNlcnZlciB0b3BpYw0KDQpIaSBhbGwsDQoNCmFzIEkgYW0gcHJlcGFyaW5nIGFu
b3RoZXIgZHJhZnQgdXBkYXRlIG9mIHRoZSBwcm9maWxlIGRyYWZ0IChzZWUNCmh0dHBzOi8vZ2l0
aHViLmNvbS9oYW5uZXN0c2Nob2ZlbmlnL3RzY2hvZmVuaWctaWRzL2Jsb2IvbWFzdGVyL2RpY2Ut
cHJvZmlsZS9kcmFmdC1pZXRmLWRpY2UtcHJvZmlsZS0wNy50eHQpDQpJIHJlLXJlYWQgdGhlIGN1
cnJlbnQgd3JpdGUtdXAgYW5kIHRob3VnaHQgYWJvdXQgdGhlIG5lY2Vzc2FyeSBjaGFuZ2VzIHRv
IHN1cHBvcnQgYSBjb25zdHJhaW5lZCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24sIGkuZS4sIGFuIElv
VCBkZXZpY2UgdGhhdCBydW5zIGEgY29uc3RyYWluZWQgc2VydmVyLiBJdCB0dXJucyBvdXQgdGhh
dCB0aGUgY2hhbmdlcyBvbiB0aGUgc3VyZmFjZSBhcmUgYWN0dWFsbHkgZmFpcmx5IHNtYWxsLiBI
ZXJlIGlzIHRoZSBsaXN0IG9mIGltcGFjdGVkIHNlY3Rpb25zLg0KDQpDaGFuZ2VzIHJlcXVpcmVk
Og0KDQogLSBVc2UgU2Vzc2lvbiBSZXN1bXB0aW9uIHdpdGhvdXQgc2VydmVyLXNpZGUgc3RhdGUg
KHJhdGhlciB0aGFuIHNlc3Npb24NCnJlc3VtcHRpb24pIHRvIHB1c2ggc3RhdGUgaW5mb3JtYXRp
b24gdG8gY2xpZW50cy4NCiAtIFNlcnZlciBOYW1lIEluZGljYXRpb24gKFNOSSkgc2luY2UgaXQg
aXMgbGVzcyBsaWtlbHkgdG8gYmUgdXNlZCBvbiBhIGNvbnN0cmFpbmVkIHNlcnZlci4NCiAtIFJh
bmRvbSBOdW1iZXIgR2VuZXJhdGlvbiBiZWNhdXNlIG9mIHRoZSByZWZlcmVuY2UgdG8gW0ktRC5t
YXRoZXdzb24tbm8tZ210dW5peHRpbWVdLiAoc21hbGwgY2hhbmdlKS4NCg0KTm8gY2hhbmdlOg0K
DQogLSBQZXJmZWN0IEZvcndhcmQgU2VjcmVjeQ0KIC0gS2VlcC1BbGl2ZQ0KIC0gVGltZW91dHMN
CiAtIFRydW5jYXRlZCBNQUMgYW5kIEVuY3J5cHQtdGhlbi1NQUMgRXh0ZW5zaW9uDQogLSBNYXhp
bXVtIEZyYWdtZW50IExlbmd0aCBOZWdvdGlhdGlvbg0KIC0gU2Vzc2lvbiBIYXNoDQogLSBSZS1O
ZWdvdGlhdGlvbiBBdHRhY2tzDQogLSBEb3duZ3JhZGluZyBBdHRhY2tzDQogLSBDcnlwdG8gQWdp
bGl0eQ0KIC0gS2V5IExlbmd0aCBSZWNvbW1lbmRhdGlvbnMNCiAtIEZhbHNlIFN0YXJ0DQoNClRo
ZSBjaGFsbGVuZ2VzIGRvLCBob3dldmVyLCBzdGFydCB3aGVuIGl0IGNvbWVzIHRvIHRoZSBhc3N1
bXB0aW9ucyBiZWhpbmQgbWFkZSBieSB0aGUgY3VycmVudCB0ZXh0LiBBcyB0aGUgdGV4dCBpcyBj
dXJyZW50bHkgd3JpdHRlbiwgdGhlIGFzc3VtcHRpb24gaXMgdGhhdCB0aGVyZSBpcyBhIHZlcnkg
Y2xvc2UgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGNvbnN0cmFpbmVkIGNsaWVudCBhbmQgdGhl
IHNlcnZlciAod2hpY2ggaXMgc2l0dGluZyBzb21ld2hlcmUgaW4gdGhlIGNsb3VkKS4gVGhpcyBp
cyBhIHF1aXRlIHJlYWxpc3RpYyB1c2FnZSBtb2RlbCBzaW5jZSB0aGlzIGlzIHdoYXQgd2UgYXJl
IHNlZWluZyB0b2RheSB3aXRoIG1hbnkgZGVwbG95bWVudHMgd2hlcmUgdGhlIGRldmljZSBtYWtl
ciBhbHNvIHByb3ZpZGVzIHRoZSBjb3JyZXNwb25kaW5nIHNlcnZlci1zaWRlIGluZnJhc3RydWN0
dXJlLg0KDQpUaGlzIGdpdmVzIHRoZSB2ZW5kb3IgYSBsb3Qgb2YgZnJlZWRvbSB3aXRoIHJlZ2Fy
ZCB0byB0aGUgdXNlIG9mIHRoZSBjcmVkZW50aWFscyBhbmQgYWxzbyB0byBpbXBsZW1lbnQgYSBz
b2Z0d2FyZSB1cGRhdGUgbWVjaGFuaXNtIHRoZSBkZXZpY2UgY2FuIHVzZSB0byBkZWFsIHdpdGgg
ZnVuY3Rpb25hbGl0eSBsaWtlIHJldm9jYXRpb24gYW5kIHRydXN0IGFuY2hvciBwcm92aXNpb25p
bmcuDQoNClRoZXJlIGlzIGFsc28gbm8gcHJvYmxlbSB3aXRoIGRpc2NvdmVyeSAoc2luY2Ugd2Ug
YXNzdW1lIHRoYXQgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzZXJ2ZXIgaXMgcHJlLWNvbmZp
Z3VyZWQpLiBUaGVyZSBpcyBhbHNvIG5vdCBwcm9ibGVtIHdpdGggcmVhY2hhYmlsaXR5IHNpbmNl
IHRoZSBjbGllbnQgc3RhcnRzIHRoZSBjb21tdW5pY2F0aW9uIGV4Y2hhbmdlLg0KDQpOb3csIGFz
IHdlIG1vdmUgdG8gYSBkaWZmZXJlbnQgZGVzaWduIHBhdHRlcm4sIHN1Y2ggYXMgdGhlIGRldmlj
ZS10by1kZXZpY2UgY29tbXVuaWNhdGlvbiBtb2RlbCB0aGVzZSBhc3N1bXB0aW9ucyBzdWRkZW5s
eSBkbyBub3Qgd29yayBhbnltb3JlLiBJdCB0dXJucyBvdXQgdGhhdCB0aGUgZGlmZmVyZW50aWF0
aW9uIGJldHdlZW4gY29uc3RyYWluZWQgc2VydmVyIHZzLiBjb25zdHJhaW5lZCBjbGllbnQgaXNu
J3QgYWxsIHRoYXQgcmVsZXZhbnQ7IHdoYXQgaXMgcmVsZXZhbnQgaXMgdGhlIHJlbGF0aW9uc2hp
cCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgZGV2aWNlcyBhbmQgd2hhdCBpbmZvcm1hdGlvbiBjYW4g
KG9yIGNhbm5vdCkgcmVhbGlzdGljYWxseSBhc3N1bWVkIHRvIGJlIHByZXNlbnQuDQoNCk9mIGNv
dXJzZSwgdGhlcmUgaXMgbm8gZG9jdW1lbnRhdGlvbiBvZiB0aGVzZSBkaWZmZXJlbnQgZGVzaWdu
IHBhdHRlcm5zIChvdGhlciB0aGFuIHRoZSBicmllZiB3cml0ZS11cCBpbiBodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWFiLXNtYXJ0LW9iamVjdC1hcmNoaXRlY3R1cmUtMDYpLg0K
VGhlcmUgaXMgbm8gcGxhY2UgSSBjYW4gcG9pbnQgcGVvcGxlIHRoYXQgY29udGFpbnMgYSBkZXRh
aWxlZCBkZXNjcmlwdGlvbi4NCg0KSW4gZ2VuZXJhbCwgdGhlcmUgd2lsbCBiZSB0aGUgZm9sbG93
aW5nIHByb2JsZW1zIHRvIGRlYWwgd2l0aDoNCg0KIGEpIERpc2NvdmVyeSAmIFJlYWNoYWJpbGl0
eQ0KDQpIb3cgZG9lcyB0aGUgY2xpZW50IGxlYXJuIHRoYXQgaXQgaGFzIHRvIHRhbGsgdG8gYSBz
cGVjaWZpYyBzZXJ2ZXI/DQpIb3cgZG8gdGhlIGVudGl0eSBpbml0aWF0aW5nIHRoZSBjb21tdW5p
Y2F0aW9uIGFjdHVhbGx5IHJlYWNoIHRoZSBvdGhlciBlbmQgKGFuZCBob3cgZG9lcyBpdCBtYWlu
dGFpbiB0aGF0IGNvbm5lY3Rpdml0eSk/DQoNCiBiKSBBdXRoZW50aWNhdGlvbg0KDQpXaGF0IGNy
ZWRlbnRpYWxzIGNhbiBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdHdvIHBhcnRpZXM/DQoN
CiBjKSBBdXRob3JpemF0aW9uDQoNCkhvdyBhcmUgdGhlIHR3byBwYXJ0aWVzIGdvaW5nIHRvIGF1
dGhvcml6ZSBlYWNoIG90aGVyPyBJdCBpcyBub3QganVzdCBhYm91dCBhdXRob3JpemluZyB0aGUg
Y2xpZW50IHdoZW4gaXQgYWNjZXNzZXMgYSByZXNvdXJjZSBidXQgYWxzbyBhYm91dCB0aGUgY2xp
ZW50IGVuc3VyaW5nIHRoYXQgaXQgaW5kZWVkIHRhbGtzIHRvIGEgbGVnaXRpbWF0ZSBzZXJ2ZXI/
DQoNCkRvZXMgdGhpcyBzb3VuZCBmYW1pbGlhcj8gSSBhbSBzdXJlIGl0IGRvZXMuIFRoaXMgaXMg
ZXNzZW50aWFsbHkgdGhlIEFDRSBwcm9ibGVtIHN0YXRlbWVudC4gSW4gdGhlIGN1cnJlbnQgY2xp
ZW50LXRvLWNsb3VkIG1vZGVsIGFsbCB0aGVzZSBwcm9ibGVtcyBhcmUgc29ydCBvZiAic29sdmVk
IiBieSBzaW1wbHkgYXNzdW1pbmcgdGhhdCB0aGUgY2xvdWQgc2VydmljZSBwcm92aWRlciBhbHNv
IHByb3Zpc2lvbnMgdGhlIElvVCBkZXZpY2UuIEJ1dCBpbiBhIG1vcmUgb3BlbiBtb2RlbCAod2hp
Y2ggaXMsIHF1aXRlIG5hdHVyYWxseSwgaW1wb3J0YW50IHRvIGhhdmUpIHRoZXNlIHF1ZXN0aW9u
cyBhcmUgdGhlbiBzb2x2ZWQgZWl0aGVyIHVzaW5nIHBhaXJpbmcgKGluIHRoZSB2ZXJ5IGxpbWl0
ZWQgY2FzZSwgc2VlIGRlc2NyaXB0aW9uIGluIFNlY3Rpb24gMSBvZg0KaHR0cDovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1hY2Utb3ZlcnZpZXctMDApIG9yIGJ5IGludHJv
ZHVjaW5nIHRoaXMgZmFtb3VzIHRoaXJkIHBhcnR5ICh3aGljaCBpcyB0aGUgYXV0aG9yaXphdGlv
biBzZXJ2ZXIgaW4gdGhlIEFDRSBjYXNlKS4NCg0KV2hhdCBkb2VzIHRoaXMgbWVhbiBmb3IgdGhl
IGRyYWZ0Pw0KDQpJIGNhbiBjaGVhdCBhIGxpdHRsZSBiaXQgYnkgZ2xhbmNpbmcgb3ZlciB0aGUg
aGFyZCBwcm9ibGVtcyBhbmQganVzdCBzdGFydCB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhl
IGNsaWVudCB3aWxsIHNvbWVob3cgZ2V0IHRoZSByaWdodCBjcmVkZW50aWFscywgY29uZmlndXJh
dGlvbiBpbmZvcm1hdGlvbiwgYWNjZXNzIHJpZ2h0cywgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbiwg
ZXRjLiBmcm9tIHNvbWV3aGVyZS4gSGVuY2UsIHRoaXMgaXMgYSBwdXJlIFRMUyBleGNoYW5nZSBh
bmQgSSBvbmx5IG5lZWQgdG8gbWFrZSB0aGUgbW9kaWZpY2F0aW9ucyBzdGF0ZWQgYXQgdGhlIGJl
Z2lubmluZyBvZiBteSBtYWlsLiBJIGNvdWxkIHJlZmVyZW5jZSB0aGUgb25nb2luZyBBQ0Ugd29y
aywgd2hpY2ggd2lsbCBhdCBsZWFzdCBkZWFsIHdpdGggdGhlIGF1dGhvcml6YXRpb24gcXVlc3Rp
b25zLiBPZiBjb3Vyc2UsIHRoYXQgd3JpdGUtdXAgaW4gdGhlIERJQ0UgZHJhZnQgYnkgaXRzZWxm
IGlzIG5vdCBiZSBpbnRlcm9wZXJhYmxlIGFzIGEgc3RhbmRhbG9uZSBpdGVtLg0KDQpIb3cgZG9l
cyB0aGF0IHNvdW5kPw0KDQpDaWFvDQpIYW5uZXMNCg0KDQoNCg0K


From nobody Sat Dec 13 03:12:18 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC231A0020 for ; Sat, 13 Dec 2014 03:12:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 takWTLp_ScTJ for ; Sat, 13 Dec 2014 03:12:14 -0800 (PST)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2154C1A001C for ; Sat, 13 Dec 2014 03:12:12 -0800 (PST)
Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 13 Dec 2014 12:12:03 +0100
Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.03.0195.001;  Sat, 13 Dec 2014 12:12:10 +0100
From: "Kovatsch  Matthias" 
To: Olaf Bergmann , Hannes Tschofenig 
Thread-Topic: [Dtls-iot] DTLS fragmentation
Thread-Index: AQHQFWaOj4lCxFyqSSKY5B7G5kKSJJyNXAeQ
Date: Sat, 13 Dec 2014 11:12:09 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B52EB43012@MBX110.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B52EB307FB@MBX110.d.ethz.ch>  <55877B3AFB359744BA0F2140E36F52B52EB3A27B@MBX110.d.ethz.ch> <87egs9w2zt.fsf@tzi.org> <54875981.6060608@gmx.net>	<878uifoee7.fsf@tzi.org> <5488499D.1050409@gmx.net>	<87oarbmy1i.fsf@tzi.org> <5488CDE3.6040507@gridmerge.com>	<5489B20E.6070900@gmx.net> <8761dicdfd.fsf@tzi.org>
In-Reply-To: <8761dicdfd.fsf@tzi.org>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [77.57.171.155]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/it0y9kur33FyWq5z649FeSuHxis
Cc: "robert.cragie@gridmerge.com" , Nikos Mavrogiannopoulos , "dtls-iot@ietf.org" 
Subject: Re: [Dtls-iot] DTLS fragmentation
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, 13 Dec 2014 11:12:17 -0000

> > a) provide examples of exchanges, including their message size.
> > [I personally would prefer to put them into the LWIG TLS document
> > instead.]

LWIG sounds like a good place.
I will try to provide some traces of different handshakes with some data li=
ke sizes and timings.

> > b) provide buffer size recommendations [While useful I don't have any
> > suggestion what to write.]
>=20
> I think (a) would be good to have (and yes, sounds more like the LWIG TLS
> document). From (a), implementors might be able to infer (b), don't they?

@Olaf: it does not matter if the buffers are static or allocated. Both ways=
 you need an idea how much should be reserved, so that all handshakes will =
work while keeping enough RAM for the rest of the system.

I think Roberts comment to dimension the buffers according to the 1280-byte=
 MTU is a good way to go. All flights of PSK and RPK handshakes fit into th=
is size. The size of certificates can explode easily, while you can also ma=
ke them fit the 1280 bytes. There might be a problem, however, when DTLS ca=
nnot re-use the IP packet buffer and needs its own buffer (e.g., when fligh=
ts a split into multiple datagrams while having only one packet buffer). Th=
en we directly blow one additional kilobyte of RAM. Hence, it would be good=
 to fix both in the profile.

Ciao
Matthias


From nobody Mon Dec 15 01:13:33 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4581D1A1A98; Mon, 15 Dec 2014 01:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqS-1uA6XYfH; Mon, 15 Dec 2014 01:13:24 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 755AF1A1A8F; Mon, 15 Dec 2014 01:13:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141215091318.29697.12652.idtracker@ietfa.amsl.com>
Date: Mon, 15 Dec 2014 01:13:18 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/zyl4mBqRy1i8jtmM-G43BtoM0ig
Cc: dtls-iot@ietf.org
Subject: [Dtls-iot] I-D Action: draft-ietf-dice-profile-07.txt
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DTLS for IoT discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Dec 2014 09:13:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DTLS In Constrained Environments Working Group of the IETF.

        Title           : A TLS/DTLS 1.2 Profile for the Internet of Things
        Authors         : Hannes Tschofenig
                          Thomas Fossati
	Filename        : draft-ietf-dice-profile-07.txt
	Pages           : 42
	Date            : 2014-12-15

Abstract:
   A common design pattern in Internet of Things (IoT) deployments is
   the use of a constrained device (typically providing sensor data)
   that makes data available for home automation, industrial control
   systems, smart cities and other IoT deployments.

   This document defines a Transport Layer Security (TLS) and Datagram
   TLS 1.2 profile that offers communications security for this data
   exchange thereby preventing eavesdropping, tampering, and message
   forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dice-profile/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dice-profile-07

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Dec 15 01:33:33 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3721A1A97 for ; Mon, 15 Dec 2014 01:33:31 -0800 (PST)
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 6dgGYeYdBd4N for ; Mon, 15 Dec 2014 01:33:30 -0800 (PST)
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 B0C7B1A1A96 for ; Mon, 15 Dec 2014 01:33:29 -0800 (PST)
Received: from [192.168.131.137] ([80.92.123.25]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LoEwL-1XTbG21Pwn-00gE6W for ; Mon, 15 Dec 2014 10:33:27 +0100
Message-ID: <548EAAE6.9060601@gmx.net>
Date: Mon, 15 Dec 2014 10:33:26 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.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="PKFqTI0xR7hDn713i5KIrNiRU8ptwkr3q"
X-Provags-ID: V03:K0:c1Tnge8wTqOuuDyJ2Qxweeo2OmjPuaXQLX5f6BLWAYC5vqQ93MA N7lT9s6dyHjHuQZN9MY+mkJE9XVEZbpKzlKYH+gJM+f0fpw00krp9kPunH6wx2zppWAkNFs has6UhhbImg/S5UyzpaFkN9qtrKzE5eFYo3d+3wom/kLe/zE03oGVwTzS8gcS4xNbzxgiVM vSPj9UhNpYvNxEm8ZB/3Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/zPIdA-s-9eFxfVGqxAvzddfPkNE
Subject: [Dtls-iot] draft-ietf-dice-profile-07.txt
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, 15 Dec 2014 09:33:32 -0000

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

Hi all,

I have just uploaded another snapshot and you can find it here:
http://www.ietf.org/id/draft-ietf-dice-profile-07.txt

The following issues have been addressed by this update:

* Issue#17: AES-CCM nonces in DTLS records
https://tools.ietf.org/wg/dice/trac/ticket/17

* Issue#21: Downgrading Attacks and tls-downgrade-scsv
https://tools.ietf.org/wg/dice/trac/ticket/21

* Issue#22: DTLS / TLS Use for Network Access Authentication
https://tools.ietf.org/wg/dice/trac/ticket/22

* Issue#11: Relevance of Guidance Document for TLS
http://trac.tools.ietf.org/wg/dice/trac/ticket/11

There are still open issues, namely
 * the desire to cover constrained servers, and
 * DTLS fragmentation.

Here is the description for the open issues:
http://trac.tools.ietf.org/wg/dice/trac/report/1

My plan is to get another update submitted by the end of this week that
addresses these two issues and review comments from Ekr.

Ciao
Hannes


--PKFqTI0xR7hDn713i5KIrNiRU8ptwkr3q
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

iQEcBAEBCgAGBQJUjqrnAAoJEGhJURNOOiAt/ygIAKXhEFTkjhOV9KCWjpBdjCSR
njY88ekni3/lUBezyYDajnrZhrvCqsCcqlJcOrmTYkBXCLAQtOgBMZPp7GOnZd+H
nQu85znGbfBn/wM1pJceKIAYVhTJ7h/urWvOlMNZhUEMGCiTu7/5FANYMabFbXwk
SaRp1fTSZ6f+OlOnyEe/Crh7NsANmdbemOeeoMcb6f1GtDPZmhoj6mxl1MQV6z3+
79Fq0aGA6KYicnL2i8REwUNTI2bN/wUX0/6Lvuxoy6Vl2zPheUn6OItxfd6FAL6C
1aw+cWxoP7APyFO3iN9GXld7N7uEDv6QsX5lx8Wic/nEoq3OXrHoZR3iglMmhcE=
=9L7X
-----END PGP SIGNATURE-----

--PKFqTI0xR7hDn713i5KIrNiRU8ptwkr3q--


From nobody Mon Dec 15 02:42:26 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625C61A1ADC for ; Mon, 15 Dec 2014 02:42:25 -0800 (PST)
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 i2ZczEtpezAO for ; Mon, 15 Dec 2014 02:42:22 -0800 (PST)
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 8FF281A1ADB for ; Mon, 15 Dec 2014 02:42:22 -0800 (PST)
Received: from [192.168.131.137] ([80.92.123.25]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlUZz-1XPlAz48EZ-00bGuB; Mon, 15 Dec 2014 11:42:19 +0100
Message-ID: <548EBB09.4010509@gmx.net>
Date: Mon, 15 Dec 2014 11:42:17 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Rahman, Akbar" ,  "dtls-iot@ietf.org" 
References: <548AC461.7080203@gmx.net> <36F5869FE31AB24485E5E3222C288E1F08DCA1@NABESITE.InterDigital.com>
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F08DCA1@NABESITE.InterDigital.com>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jUqiWAG0XQ6G8QL8EwDHkk7aNsVxL3wpS"
X-Provags-ID: V03:K0:WeEPBr7BaXddicaU61P2cypVxT+J992qe/5KsFgoemS+i3rVjV3 Ft7FupaL5jridSxSgUVNNUsPubGQXP4weGTbCTXO311IXz6tiraoyWWXsQwrPhxpT8fHyGw VcOI4lVEPSKKUzEh1IfZVCnoaUhcRFS9y7CdqBlAxmkz+X4msRgp/VPTmjCc82Lc3viSct1 jKxXkAkORcWELGVMwqI+Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/nVBtUFCtinG3WVnnDQYh8AgujcU
Subject: Re: [Dtls-iot] Making progress on the constrained server topic
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, 15 Dec 2014 10:42:25 -0000

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

Hi Akbar,

thanks for your input and for pointing to relevant documents.

The CoAP mechanisms have been worked out quite well for local discovery.
Of course, there are other discovery techniques out there (such as
http://datatracker.ietf.org/wg/dnssd/charter/) and there is also the
issue of discovering nodes that are not in the local network.

What I could do is to cite these documents as an example of how this
works with CoAP. This provides enough information for the reader to get
the bigger picture and then, for the actual details, look at the
relevant documents. If something else other than CoAP is used then that
reader has to find the relevant information.

What do you think about my suggested approach for dealing with the other
issues since they are all related to each other?

On 12/12/2014 07:53 PM, Rahman, Akbar wrote:
> Hi Hannes,
>=20
>=20
> Thank you very much for the continued effort on this topic.  As you
> know, I strongly support considering the constrained server case in
> your document.  I would like to give feedback on one of the key
> points from your detailed analysis:
>=20
>> a) Discovery & Reachability
>>=20
>> How does the client learn that it has to talk to a specific
>> server?
>=20
>=20
> If we consider CoAP as the application protocol being run between the
> IoT device and the constrained server then the answer is clear.
> Discovery (of resources and/or servers) is done by sending a unicast
> or multicast CoAP GET to a well-known URI.  Various aspects of this
> discovery is explained in multiple RFCs/drafts:
>=20
> 1) The CORE Link format document [RFC 6690] which first described the
> use case, and reserved the URI: - Use Case:
> http://tools.ietf.org/html/rfc6690#section-1.2.1 - Reserving the URI:
> http://tools.ietf.org/html/rfc6690#section-7.1
>=20
> 2) The CoAP spec [RFC 7252] also provides a nice summary of the
> operation: - http://tools.ietf.org/html/rfc7252#section-7
>=20
> 3) The CoAP Group Communications spec [RFC 7390] gives a detailed use
> case on how to multicast discover CoAP servers, and the protocol
> processing rules: - Use Case:
> http://tools.ietf.org/html/rfc7390#section-3.3 - Protocol processing
> (see 5th sub-bullet) : http://tools.ietf.org/html/rfc7390#section-2.7
>=20
>=20
>=20
> So, my opinion is that this issue is well solved at least for the
> CoAP case.  Do you agre?
>=20
>=20
>=20
>> How do the entity initiating the communication actually reach the
>> other end (and how does it maintain that connectivity)?
>=20
> I think Carsten previously gave a good answer to a similar question:
>=20
> - http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00474.html
>=20

My reading of his response was that
 * he believes that there are many firewall traversal mechanisms already
that can be re-used, and
 * he does not believe in IPv4 for IoT deployments (and hence there is
no NAT traversal issue).

That's one view.

Ciao
Hannes

>=20
>=20
>=20
> Best Regards,
>=20
>=20
> Akbar
>=20
>=20
>=20
> -----Original Message----- From: dtls-iot
> [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Hannes Tschofenig=20
> Sent: Friday, December 12, 2014 5:33 AM To: dtls-iot@ietf.org=20
> Subject: [Dtls-iot] Making progress on the constrained server topic
>=20
> Hi all,
>=20
> as I am preparing another draft update of the profile draft (see=20
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-pro=
file/draft-ietf-dice-profile-07.txt)
>
> I re-read the current write-up and thought about the necessary changes
to support a constrained server implementation, i.e., an IoT device that
runs a constrained server. It turns out that the changes on the surface
are actually fairly small. Here is the list of impacted sections.
>=20
> Changes required:
>=20
> - Use Session Resumption without server-side state (rather than
> session resumption) to push state information to clients. - Server
> Name Indication (SNI) since it is less likely to be used on a
> constrained server. - Random Number Generation because of the
> reference to [I-D.mathewson-no-gmtunixtime]. (small change).
>=20
> No change:
>=20
> - Perfect Forward Secrecy - Keep-Alive - Timeouts - Truncated MAC and
> Encrypt-then-MAC Extension - Maximum Fragment Length Negotiation -
> Session Hash - Re-Negotiation Attacks - Downgrading Attacks - Crypto
> Agility - Key Length Recommendations - False Start
>=20
> The challenges do, however, start when it comes to the assumptions
> behind made by the current text. As the text is currently written,
> the assumption is that there is a very close relationship between the
> constrained client and the server (which is sitting somewhere in the
> cloud). This is a quite realistic usage model since this is what we
> are seeing today with many deployments where the device maker also
> provides the corresponding server-side infrastructure.
>=20
> This gives the vendor a lot of freedom with regard to the use of the
> credentials and also to implement a software update mechanism the
> device can use to deal with functionality like revocation and trust
> anchor provisioning.
>=20
> There is also no problem with discovery (since we assume that the
> information about the server is pre-configured). There is also not
> problem with reachability since the client starts the communication
> exchange.
>=20
> Now, as we move to a different design pattern, such as the
> device-to-device communication model these assumptions suddenly do
> not work anymore. It turns out that the differentiation between
> constrained server vs. constrained client isn't all that relevant;
> what is relevant is the relationship between the different devices
> and what information can (or cannot) realistically assumed to be
> present.
>=20
> Of course, there is no documentation of these different design
> patterns (other than the brief write-up in
> https://tools.ietf.org/html/draft-iab-smart-object-architecture-06).=20
> There is no place I can point people that contains a detailed
> description.
>=20
> In general, there will be the following problems to deal with:
>=20
> a) Discovery & Reachability
>=20
> How does the client learn that it has to talk to a specific server?=20
> How do the entity initiating the communication actually reach the
> other end (and how does it maintain that connectivity)?
>=20
> b) Authentication
>=20
> What credentials can be used to authenticate the two parties?
>=20
> c) Authorization
>=20
> How are the two parties going to authorize each other? It is not just
> about authorizing the client when it accesses a resource but also
> about the client ensuring that it indeed talks to a legitimate
> server?
>=20
> Does this sound familiar? I am sure it does. This is essentially the
> ACE problem statement. In the current client-to-cloud model all these
> problems are sort of "solved" by simply assuming that the cloud
> service provider also provisions the IoT device. But in a more open
> model (which is, quite naturally, important to have) these questions
> are then solved either using pairing (in the very limited case, see
> description in Section 1 of=20
> http://tools.ietf.org/html/draft-tschofenig-ace-overview-00) or by
> introducing this famous third party (which is the authorization
> server in the ACE case).
>=20
> What does this mean for the draft?
>=20
> I can cheat a little bit by glancing over the hard problems and just
> start with the assumption that the client will somehow get the right
> credentials, configuration information, access rights, revocation
> information, etc. from somewhere. Hence, this is a pure TLS exchange
> and I only need to make the modifications stated at the beginning of
> my mail. I could reference the ongoing ACE work, which will at least
> deal with the authorization questions. Of course, that write-up in
> the DICE draft by itself is not be interoperable as a standalone
> item.
>=20
> How does that sound?
>=20
> Ciao Hannes
>=20
>=20
>=20
>=20


--jUqiWAG0XQ6G8QL8EwDHkk7aNsVxL3wpS
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

iQEcBAEBCgAGBQJUjrsJAAoJEGhJURNOOiAtg+UH/2qHKSfh2CmEnF5tfwRk4irh
nVl+6LZt9waH51RuLltlS/zRJ+HA86jAFWwr/DcSuclnB9XkDGVdTdtFDgIFaUvN
gmVAW1nRC1wufbJprGkPWGosbXqI7ENCfBDmY3FAT4G0sPyX55VNz723LpUzwpob
4lud65aIbHaZ8TL8vyjsz2E3LE8gfhR0CiZn+UXIF+PIYY/NEChPCfc4JqIP28Zl
zqDuFqYBl/qRfQnkhji3YYVejZxNJbp2SKpV91VMuhqY1RNP4pO0vj8q9XiIy8mu
zFRk3nGvxoHu16+Iq8Zp1OstG1XmAlGxmzlzUwR0xF2mPB4hTnsHtQDdWymklqI=
=QVBr
-----END PGP SIGNATURE-----

--jUqiWAG0XQ6G8QL8EwDHkk7aNsVxL3wpS--


From nobody Mon Dec 15 10:42:00 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82F51A8758 for ; Mon, 15 Dec 2014 10:41:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.245
X-Spam-Level: 
X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_pqYAYBCVea for ; Mon, 15 Dec 2014 10:41:56 -0800 (PST)
Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4BB1A8757 for ; Mon, 15 Dec 2014 10:41:56 -0800 (PST)
X-ASG-Debug-ID: 1418668914-06daaa512683a00001-roOjxa
Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id lFixUw58Z02wIGXa for ; Mon, 15 Dec 2014 13:41:54 -0500 (EST)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 15 Dec 2014 13:41:54 -0500
Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 15 Dec 2014 13:41:54 -0500
Received: from NALENITE.InterDigital.com (10.2.64.253) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 15 Dec 2014 13:41:53 -0500
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 13:41:52 -0500
From: "Rahman, Akbar" 
To: Hannes Tschofenig , "dtls-iot@ietf.org" 
Thread-Topic: [Dtls-iot] Making progress on the constrained server topic
X-ASG-Orig-Subj: RE: [Dtls-iot] Making progress on the constrained server topic
Thread-Index: AQHQFfcKjxHA38OSMkWo7vTsCDVsGZyMRpZggASI5ICAACHD4A==
Date: Mon, 15 Dec 2014 18:41:51 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F08E6F0@NABESITE.InterDigital.com>
References: <548AC461.7080203@gmx.net> <36F5869FE31AB24485E5E3222C288E1F08DCA1@NABESITE.InterDigital.com> <548EBB09.4010509@gmx.net>
In-Reply-To: <548EBB09.4010509@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.17]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Dec 2014 18:41:54.0327 (UTC) FILETIME=[CC2AEA70:01D01896]
X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27]
X-Barracuda-Start-Time: 1418668914
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.12936 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/OOJq4X9IictCxQ26XgdIW5WzTYQ
Subject: Re: [Dtls-iot] Making progress on the constrained server topic
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, 15 Dec 2014 18:41:59 -0000

SGkgSGFubmVzLA0KDQoNCj4gVGhlIENvQVAgbWVjaGFuaXNtcyBoYXZlIGJlZW4gd29ya2VkIG91
dCBxdWl0ZSB3ZWxsIGZvciBsb2NhbCBkaXNjb3ZlcnkgLi4uIA0KDQpQbGVhc2Ugbm90ZSB0aGF0
IENvQVAgcmVzZXJ2ZXMgdGhlICJBbGwgQ29BUCBOb2RlcyIgbXVsdGljYXN0IGFkZHJlc3NlcyB0
byB3b3JrIGJleW9uZCBqdXN0IHRoZSBsaW5rLWxvY2FsOiAgDQoNCgktICJBIHNlcnZlciBpcyBk
aXNjb3ZlcmVkIGJ5IGEgY2xpZW50IChrbm93aW5nIG9yKSBsZWFybmluZyBhIFVSSSB0aGF0DQoJ
cmVmZXJlbmNlcyBhIHJlc291cmNlIGluIHRoZSBuYW1lc3BhY2Ugb2YgdGhlIHNlcnZlci4gIEFs
dGVybmF0aXZlbHksDQoJY2xpZW50cyBjYW4gdXNlIG11bHRpY2FzdCBDb0FQIChzZWUgU2VjdGlv
biA4KSBhbmQgdGhlICJBbGwgQ29BUA0KCU5vZGVzIiBtdWx0aWNhc3QgYWRkcmVzcyB0byBmaW5k
IENvQVAgc2VydmVycy4iDQoJaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0
aW9uLTcuMQ0KDQoNCgktIFRoZSBkaWZmZXJlbnQgbXVsdGljYXN0IHNjb3BlcyBhcmUgZGVzY3Jp
YmVkIGluOg0KCWh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjc2VjdGlvbi0xMi44
IA0KDQoJIC0gKFRob3VnaCBJIGFtIG5vdCB0cnlpbmcgdG8gdHJpdmlhbGl6ZSB0aGUgcHJhY3Rp
Y2FsIGRpZmZpY3VsdGllcyBvZiBzZXR0aW5nIHVwIHRoZSBtdWx0aWNhc3Qgcm91dGluZyB0byB3
b3JrIGJleW9uZCBhIGxpbmstbG9jYWwuKSAgDQoNCg0KDQo+V2hhdCBJIGNvdWxkIGRvIGlzIHRv
IGNpdGUgdGhlc2UgZG9jdW1lbnRzIGFzIGFuIGV4YW1wbGUgb2YgaG93IHRoaXMgd29ya3Mgd2l0
aCBDb0FQLiBUaGlzIHByb3ZpZGVzIGVub3VnaCBpbmZvcm1hdGlvbiBmb3IgdGhlIHJlYWRlciB0
byBnZXQgdGhlIGJpZ2dlciBwaWN0dXJlIGFuZCB0aGVuLCBmb3IgdGhlIGFjdHVhbCBkZXRhaWxz
LCBsb29rIGF0IHRoZSByZWxldmFudCBkb2N1bWVudHMuIElmIHNvbWV0aGluZyBlbHNlIG90aGVy
IHRoYW4gQ29BUCBpcyB1c2VkIHRoZW4gdGhhdCByZWFkZXIgaGFzIHRvIGZpbmQgdGhlIHJlbGV2
YW50IGluZm9ybWF0aW9uLg0KDQpZZXMsIEkgdGhpbmsgdGhpcyBpcyBhIHZlcnkgZ29vZCBhcHBy
b2FjaC4NCg0KDQoNCj4gV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgbXkgc3VnZ2VzdGVkIGFwcHJv
YWNoIGZvciBkZWFsaW5nIHdpdGggdGhlIG90aGVyIGlzc3VlcyBzaW5jZSB0aGV5IGFyZSBhbGwg
cmVsYXRlZCB0byBlYWNoIG90aGVyPw0KDQpJIGFncmVlIHdpdGggeW91ciBzdWdnZXN0aW9uIGZv
ciBwb2ludGluZyB0byB0aGUgQUNFIFdHIGZvciB0aGUgQXV0aGVudGljYXRpb24gYW5kIEF1dGhv
cml6YXRpb24gYXNzdW1wdGlvbnMuICANCg0KDQoNCj4gT2YgY291cnNlLCB0aGVyZSBpcyBubyBk
b2N1bWVudGF0aW9uIG9mIHRoZXNlIGRpZmZlcmVudCBkZXNpZ24gcGF0dGVybnMgKG90aGVyIHRo
YW4gdGhlIGJyaWVmIHdyaXRlLXVwIGluIC4uLg0KDQpJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBp
cyBtdWNoIG9mIGFuIGlzc3VlLCBmcmFua2x5LCBiZWNhdXNlIHRoaXMgaXMgdGhlIG1vZGVsIHRo
YXQgZXZlcnlvbmUgd2hvIHRhbGtzIGFib3V0IElvVCBhbHJlYWR5IGhhcyBpbiB0aGVpciBoZWFk
LiAgDQoNCkNhdmVhdHM6DQoJLUkgYW0gYXNzdW1pbmcgdGhhdCBpbiB5b3VyIHBsYWNlIGhvbGRl
ciBzZWN0aW9uIDQuMiB5b3Ugd2lsbCBhbHNvIHB1dCBhIG5ldyBGaWd1cmUgYW5hbG9nb3VzIHRv
IEZpZ3VyZSAxLCBhbmQgdGhhdCB5b3Ugd2lsbCBkZXNjcmliZSB0aGUgbm9uLWNsb3VkIGJhc2Vk
IHBhcmFkaWdtIGFzIHlvdSBoYXZlIG5pY2VseSBzdW1tYXJpemVkIGluIHlvdXIgb3JpZ2luYWwg
RS1tYWlsLiAgIA0KDQoJLSBCdXQsIGlmIHlvdSByZWFsbHkgdGhpbmsgdGhhdCBpdCBpcyBhbiBp
c3N1ZSwgd2h5IGRvbid0IHlvdSBzaW1wbHkgcHV0IGEgcmVmZXJlbmNlIHRvIHlvdXIgaWFiLXNt
YXJ0LW9iamVjdC1hcmNoaXRlY3R1cmUgZHJhZnQgYXMgaXQgZGVzY3JpYmVzIHRoZSBtb2RlbHMg
bmljZWx5Pw0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpBa2Jhcg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgW21haWx0bzpoYW5uZXMu
dHNjaG9mZW5pZ0BnbXgubmV0XSANClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTUsIDIwMTQgNTo0
MiBBTQ0KVG86IFJhaG1hbiwgQWtiYXI7IGR0bHMtaW90QGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W0R0bHMtaW90XSBNYWtpbmcgcHJvZ3Jlc3Mgb24gdGhlIGNvbnN0cmFpbmVkIHNlcnZlciB0b3Bp
Yw0KDQpIaSBBa2JhciwNCg0KdGhhbmtzIGZvciB5b3VyIGlucHV0IGFuZCBmb3IgcG9pbnRpbmcg
dG8gcmVsZXZhbnQgZG9jdW1lbnRzLg0KDQpUaGUgQ29BUCBtZWNoYW5pc21zIGhhdmUgYmVlbiB3
b3JrZWQgb3V0IHF1aXRlIHdlbGwgZm9yIGxvY2FsIGRpc2NvdmVyeS4NCk9mIGNvdXJzZSwgdGhl
cmUgYXJlIG90aGVyIGRpc2NvdmVyeSB0ZWNobmlxdWVzIG91dCB0aGVyZSAoc3VjaCBhcw0KaHR0
cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2Ruc3NkL2NoYXJ0ZXIvKSBhbmQgdGhlcmUgaXMg
YWxzbyB0aGUgaXNzdWUgb2YgZGlzY292ZXJpbmcgbm9kZXMgdGhhdCBhcmUgbm90IGluIHRoZSBs
b2NhbCBuZXR3b3JrLg0KDQpXaGF0IEkgY291bGQgZG8gaXMgdG8gY2l0ZSB0aGVzZSBkb2N1bWVu
dHMgYXMgYW4gZXhhbXBsZSBvZiBob3cgdGhpcyB3b3JrcyB3aXRoIENvQVAuIFRoaXMgcHJvdmlk
ZXMgZW5vdWdoIGluZm9ybWF0aW9uIGZvciB0aGUgcmVhZGVyIHRvIGdldCB0aGUgYmlnZ2VyIHBp
Y3R1cmUgYW5kIHRoZW4sIGZvciB0aGUgYWN0dWFsIGRldGFpbHMsIGxvb2sgYXQgdGhlIHJlbGV2
YW50IGRvY3VtZW50cy4gSWYgc29tZXRoaW5nIGVsc2Ugb3RoZXIgdGhhbiBDb0FQIGlzIHVzZWQg
dGhlbiB0aGF0IHJlYWRlciBoYXMgdG8gZmluZCB0aGUgcmVsZXZhbnQgaW5mb3JtYXRpb24uDQoN
CldoYXQgZG8geW91IHRoaW5rIGFib3V0IG15IHN1Z2dlc3RlZCBhcHByb2FjaCBmb3IgZGVhbGlu
ZyB3aXRoIHRoZSBvdGhlciBpc3N1ZXMgc2luY2UgdGhleSBhcmUgYWxsIHJlbGF0ZWQgdG8gZWFj
aCBvdGhlcj8NCg0KT24gMTIvMTIvMjAxNCAwNzo1MyBQTSwgUmFobWFuLCBBa2JhciB3cm90ZToN
Cj4gSGkgSGFubmVzLA0KPiANCj4gDQo+IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBjb250
aW51ZWQgZWZmb3J0IG9uIHRoaXMgdG9waWMuICBBcyB5b3UgDQo+IGtub3csIEkgc3Ryb25nbHkg
c3VwcG9ydCBjb25zaWRlcmluZyB0aGUgY29uc3RyYWluZWQgc2VydmVyIGNhc2UgaW4gDQo+IHlv
dXIgZG9jdW1lbnQuICBJIHdvdWxkIGxpa2UgdG8gZ2l2ZSBmZWVkYmFjayBvbiBvbmUgb2YgdGhl
IGtleSBwb2ludHMgDQo+IGZyb20geW91ciBkZXRhaWxlZCBhbmFseXNpczoNCj4gDQo+PiBhKSBE
aXNjb3ZlcnkgJiBSZWFjaGFiaWxpdHkNCj4+IA0KPj4gSG93IGRvZXMgdGhlIGNsaWVudCBsZWFy
biB0aGF0IGl0IGhhcyB0byB0YWxrIHRvIGEgc3BlY2lmaWMgc2VydmVyPw0KPiANCj4gDQo+IElm
IHdlIGNvbnNpZGVyIENvQVAgYXMgdGhlIGFwcGxpY2F0aW9uIHByb3RvY29sIGJlaW5nIHJ1biBi
ZXR3ZWVuIHRoZQ0KPiBJb1QgZGV2aWNlIGFuZCB0aGUgY29uc3RyYWluZWQgc2VydmVyIHRoZW4g
dGhlIGFuc3dlciBpcyBjbGVhci4NCj4gRGlzY292ZXJ5IChvZiByZXNvdXJjZXMgYW5kL29yIHNl
cnZlcnMpIGlzIGRvbmUgYnkgc2VuZGluZyBhIHVuaWNhc3QNCj4gb3IgbXVsdGljYXN0IENvQVAg
R0VUIHRvIGEgd2VsbC1rbm93biBVUkkuICBWYXJpb3VzIGFzcGVjdHMgb2YgdGhpcw0KPiBkaXNj
b3ZlcnkgaXMgZXhwbGFpbmVkIGluIG11bHRpcGxlIFJGQ3MvZHJhZnRzOg0KPiANCj4gMSkgVGhl
IENPUkUgTGluayBmb3JtYXQgZG9jdW1lbnQgW1JGQyA2NjkwXSB3aGljaCBmaXJzdCBkZXNjcmli
ZWQgdGhlDQo+IHVzZSBjYXNlLCBhbmQgcmVzZXJ2ZWQgdGhlIFVSSTogLSBVc2UgQ2FzZToNCj4g
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjY5MCNzZWN0aW9uLTEuMi4xIC0gUmVzZXJ2
aW5nIHRoZSBVUkk6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY2OTAjc2VjdGlv
bi03LjENCj4gDQo+IDIpIFRoZSBDb0FQIHNwZWMgW1JGQyA3MjUyXSBhbHNvIHByb3ZpZGVzIGEg
bmljZSBzdW1tYXJ5IG9mIHRoZQ0KPiBvcGVyYXRpb246IC0gaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjNzI1MiNzZWN0aW9uLTcNCj4gDQo+IDMpIFRoZSBDb0FQIEdyb3VwIENvbW11bmlj
YXRpb25zIHNwZWMgW1JGQyA3MzkwXSBnaXZlcyBhIGRldGFpbGVkIHVzZQ0KPiBjYXNlIG9uIGhv
dyB0byBtdWx0aWNhc3QgZGlzY292ZXIgQ29BUCBzZXJ2ZXJzLCBhbmQgdGhlIHByb3RvY29sDQo+
IHByb2Nlc3NpbmcgcnVsZXM6IC0gVXNlIENhc2U6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzczOTAjc2VjdGlvbi0zLjMgLSBQcm90b2NvbCBwcm9jZXNzaW5nDQo+IChzZWUgNXRo
IHN1Yi1idWxsZXQpIDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzM5MCNzZWN0aW9u
LTIuNw0KPiANCj4gDQo+IA0KPiBTbywgbXkgb3BpbmlvbiBpcyB0aGF0IHRoaXMgaXNzdWUgaXMg
d2VsbCBzb2x2ZWQgYXQgbGVhc3QgZm9yIHRoZQ0KPiBDb0FQIGNhc2UuICBEbyB5b3UgYWdyZT8N
Cj4gDQo+IA0KPiANCj4+IEhvdyBkbyB0aGUgZW50aXR5IGluaXRpYXRpbmcgdGhlIGNvbW11bmlj
YXRpb24gYWN0dWFsbHkgcmVhY2ggdGhlDQo+PiBvdGhlciBlbmQgKGFuZCBob3cgZG9lcyBpdCBt
YWludGFpbiB0aGF0IGNvbm5lY3Rpdml0eSk/DQo+IA0KPiBJIHRoaW5rIENhcnN0ZW4gcHJldmlv
dXNseSBnYXZlIGEgZ29vZCBhbnN3ZXIgdG8gYSBzaW1pbGFyIHF1ZXN0aW9uOg0KPiANCj4gLSBo
dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZHRscy1pb3QvY3VycmVudC9tc2cw
MDQ3NC5odG1sDQo+IA0KDQpNeSByZWFkaW5nIG9mIGhpcyByZXNwb25zZSB3YXMgdGhhdA0KICog
aGUgYmVsaWV2ZXMgdGhhdCB0aGVyZSBhcmUgbWFueSBmaXJld2FsbCB0cmF2ZXJzYWwgbWVjaGFu
aXNtcyBhbHJlYWR5DQp0aGF0IGNhbiBiZSByZS11c2VkLCBhbmQNCiAqIGhlIGRvZXMgbm90IGJl
bGlldmUgaW4gSVB2NCBmb3IgSW9UIGRlcGxveW1lbnRzIChhbmQgaGVuY2UgdGhlcmUgaXMNCm5v
IE5BVCB0cmF2ZXJzYWwgaXNzdWUpLg0KDQpUaGF0J3Mgb25lIHZpZXcuDQoNCkNpYW8NCkhhbm5l
cw0KDQo+IA0KPiANCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gDQo+IA0KPiBBa2Jhcg0KPiANCj4g
DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBkdGxzLWlvdA0KPiBbbWFp
bHRvOmR0bHMtaW90LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9m
ZW5pZyANCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAxMiwgMjAxNCA1OjMzIEFNIFRvOiBkdGxz
LWlvdEBpZXRmLm9yZyANCj4gU3ViamVjdDogW0R0bHMtaW90XSBNYWtpbmcgcHJvZ3Jlc3Mgb24g
dGhlIGNvbnN0cmFpbmVkIHNlcnZlciB0b3BpYw0KPiANCj4gSGkgYWxsLA0KPiANCj4gYXMgSSBh
bSBwcmVwYXJpbmcgYW5vdGhlciBkcmFmdCB1cGRhdGUgb2YgdGhlIHByb2ZpbGUgZHJhZnQgKHNl
ZSANCj4gaHR0cHM6Ly9naXRodWIuY29tL2hhbm5lc3RzY2hvZmVuaWcvdHNjaG9mZW5pZy1pZHMv
YmxvYi9tYXN0ZXIvZGljZS1wcm9maWxlL2RyYWZ0LWlldGYtZGljZS1wcm9maWxlLTA3LnR4dCkN
Cj4NCj4gSSByZS1yZWFkIHRoZSBjdXJyZW50IHdyaXRlLXVwIGFuZCB0aG91Z2h0IGFib3V0IHRo
ZSBuZWNlc3NhcnkgY2hhbmdlcw0KdG8gc3VwcG9ydCBhIGNvbnN0cmFpbmVkIHNlcnZlciBpbXBs
ZW1lbnRhdGlvbiwgaS5lLiwgYW4gSW9UIGRldmljZSB0aGF0DQpydW5zIGEgY29uc3RyYWluZWQg
c2VydmVyLiBJdCB0dXJucyBvdXQgdGhhdCB0aGUgY2hhbmdlcyBvbiB0aGUgc3VyZmFjZQ0KYXJl
IGFjdHVhbGx5IGZhaXJseSBzbWFsbC4gSGVyZSBpcyB0aGUgbGlzdCBvZiBpbXBhY3RlZCBzZWN0
aW9ucy4NCj4gDQo+IENoYW5nZXMgcmVxdWlyZWQ6DQo+IA0KPiAtIFVzZSBTZXNzaW9uIFJlc3Vt
cHRpb24gd2l0aG91dCBzZXJ2ZXItc2lkZSBzdGF0ZSAocmF0aGVyIHRoYW4NCj4gc2Vzc2lvbiBy
ZXN1bXB0aW9uKSB0byBwdXNoIHN0YXRlIGluZm9ybWF0aW9uIHRvIGNsaWVudHMuIC0gU2VydmVy
DQo+IE5hbWUgSW5kaWNhdGlvbiAoU05JKSBzaW5jZSBpdCBpcyBsZXNzIGxpa2VseSB0byBiZSB1
c2VkIG9uIGENCj4gY29uc3RyYWluZWQgc2VydmVyLiAtIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlv
biBiZWNhdXNlIG9mIHRoZQ0KPiByZWZlcmVuY2UgdG8gW0ktRC5tYXRoZXdzb24tbm8tZ210dW5p
eHRpbWVdLiAoc21hbGwgY2hhbmdlKS4NCj4gDQo+IE5vIGNoYW5nZToNCj4gDQo+IC0gUGVyZmVj
dCBGb3J3YXJkIFNlY3JlY3kgLSBLZWVwLUFsaXZlIC0gVGltZW91dHMgLSBUcnVuY2F0ZWQgTUFD
IGFuZA0KPiBFbmNyeXB0LXRoZW4tTUFDIEV4dGVuc2lvbiAtIE1heGltdW0gRnJhZ21lbnQgTGVu
Z3RoIE5lZ290aWF0aW9uIC0NCj4gU2Vzc2lvbiBIYXNoIC0gUmUtTmVnb3RpYXRpb24gQXR0YWNr
cyAtIERvd25ncmFkaW5nIEF0dGFja3MgLSBDcnlwdG8NCj4gQWdpbGl0eSAtIEtleSBMZW5ndGgg
UmVjb21tZW5kYXRpb25zIC0gRmFsc2UgU3RhcnQNCj4gDQo+IFRoZSBjaGFsbGVuZ2VzIGRvLCBo
b3dldmVyLCBzdGFydCB3aGVuIGl0IGNvbWVzIHRvIHRoZSBhc3N1bXB0aW9ucw0KPiBiZWhpbmQg
bWFkZSBieSB0aGUgY3VycmVudCB0ZXh0LiBBcyB0aGUgdGV4dCBpcyBjdXJyZW50bHkgd3JpdHRl
biwNCj4gdGhlIGFzc3VtcHRpb24gaXMgdGhhdCB0aGVyZSBpcyBhIHZlcnkgY2xvc2UgcmVsYXRp
b25zaGlwIGJldHdlZW4gdGhlDQo+IGNvbnN0cmFpbmVkIGNsaWVudCBhbmQgdGhlIHNlcnZlciAo
d2hpY2ggaXMgc2l0dGluZyBzb21ld2hlcmUgaW4gdGhlDQo+IGNsb3VkKS4gVGhpcyBpcyBhIHF1
aXRlIHJlYWxpc3RpYyB1c2FnZSBtb2RlbCBzaW5jZSB0aGlzIGlzIHdoYXQgd2UNCj4gYXJlIHNl
ZWluZyB0b2RheSB3aXRoIG1hbnkgZGVwbG95bWVudHMgd2hlcmUgdGhlIGRldmljZSBtYWtlciBh
bHNvDQo+IHByb3ZpZGVzIHRoZSBjb3JyZXNwb25kaW5nIHNlcnZlci1zaWRlIGluZnJhc3RydWN0
dXJlLg0KPiANCj4gVGhpcyBnaXZlcyB0aGUgdmVuZG9yIGEgbG90IG9mIGZyZWVkb20gd2l0aCBy
ZWdhcmQgdG8gdGhlIHVzZSBvZiB0aGUNCj4gY3JlZGVudGlhbHMgYW5kIGFsc28gdG8gaW1wbGVt
ZW50IGEgc29mdHdhcmUgdXBkYXRlIG1lY2hhbmlzbSB0aGUNCj4gZGV2aWNlIGNhbiB1c2UgdG8g
ZGVhbCB3aXRoIGZ1bmN0aW9uYWxpdHkgbGlrZSByZXZvY2F0aW9uIGFuZCB0cnVzdA0KPiBhbmNo
b3IgcHJvdmlzaW9uaW5nLg0KPiANCj4gVGhlcmUgaXMgYWxzbyBubyBwcm9ibGVtIHdpdGggZGlz
Y292ZXJ5IChzaW5jZSB3ZSBhc3N1bWUgdGhhdCB0aGUNCj4gaW5mb3JtYXRpb24gYWJvdXQgdGhl
IHNlcnZlciBpcyBwcmUtY29uZmlndXJlZCkuIFRoZXJlIGlzIGFsc28gbm90DQo+IHByb2JsZW0g
d2l0aCByZWFjaGFiaWxpdHkgc2luY2UgdGhlIGNsaWVudCBzdGFydHMgdGhlIGNvbW11bmljYXRp
b24NCj4gZXhjaGFuZ2UuDQo+IA0KPiBOb3csIGFzIHdlIG1vdmUgdG8gYSBkaWZmZXJlbnQgZGVz
aWduIHBhdHRlcm4sIHN1Y2ggYXMgdGhlDQo+IGRldmljZS10by1kZXZpY2UgY29tbXVuaWNhdGlv
biBtb2RlbCB0aGVzZSBhc3N1bXB0aW9ucyBzdWRkZW5seSBkbw0KPiBub3Qgd29yayBhbnltb3Jl
LiBJdCB0dXJucyBvdXQgdGhhdCB0aGUgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4NCj4gY29uc3Ry
YWluZWQgc2VydmVyIHZzLiBjb25zdHJhaW5lZCBjbGllbnQgaXNuJ3QgYWxsIHRoYXQgcmVsZXZh
bnQ7DQo+IHdoYXQgaXMgcmVsZXZhbnQgaXMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBk
aWZmZXJlbnQgZGV2aWNlcw0KPiBhbmQgd2hhdCBpbmZvcm1hdGlvbiBjYW4gKG9yIGNhbm5vdCkg
cmVhbGlzdGljYWxseSBhc3N1bWVkIHRvIGJlDQo+IHByZXNlbnQuDQo+IA0KPiBPZiBjb3Vyc2Us
IHRoZXJlIGlzIG5vIGRvY3VtZW50YXRpb24gb2YgdGhlc2UgZGlmZmVyZW50IGRlc2lnbg0KPiBw
YXR0ZXJucyAob3RoZXIgdGhhbiB0aGUgYnJpZWYgd3JpdGUtdXAgaW4NCj4gaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlhYi1zbWFydC1vYmplY3QtYXJjaGl0ZWN0dXJlLTA2KS4g
DQo+IFRoZXJlIGlzIG5vIHBsYWNlIEkgY2FuIHBvaW50IHBlb3BsZSB0aGF0IGNvbnRhaW5zIGEg
ZGV0YWlsZWQNCj4gZGVzY3JpcHRpb24uDQo+IA0KPiBJbiBnZW5lcmFsLCB0aGVyZSB3aWxsIGJl
IHRoZSBmb2xsb3dpbmcgcHJvYmxlbXMgdG8gZGVhbCB3aXRoOg0KPiANCj4gYSkgRGlzY292ZXJ5
ICYgUmVhY2hhYmlsaXR5DQo+IA0KPiBIb3cgZG9lcyB0aGUgY2xpZW50IGxlYXJuIHRoYXQgaXQg
aGFzIHRvIHRhbGsgdG8gYSBzcGVjaWZpYyBzZXJ2ZXI/IA0KPiBIb3cgZG8gdGhlIGVudGl0eSBp
bml0aWF0aW5nIHRoZSBjb21tdW5pY2F0aW9uIGFjdHVhbGx5IHJlYWNoIHRoZQ0KPiBvdGhlciBl
bmQgKGFuZCBob3cgZG9lcyBpdCBtYWludGFpbiB0aGF0IGNvbm5lY3Rpdml0eSk/DQo+IA0KPiBi
KSBBdXRoZW50aWNhdGlvbg0KPiANCj4gV2hhdCBjcmVkZW50aWFscyBjYW4gYmUgdXNlZCB0byBh
dXRoZW50aWNhdGUgdGhlIHR3byBwYXJ0aWVzPw0KPiANCj4gYykgQXV0aG9yaXphdGlvbg0KPiAN
Cj4gSG93IGFyZSB0aGUgdHdvIHBhcnRpZXMgZ29pbmcgdG8gYXV0aG9yaXplIGVhY2ggb3RoZXI/
IEl0IGlzIG5vdCBqdXN0DQo+IGFib3V0IGF1dGhvcml6aW5nIHRoZSBjbGllbnQgd2hlbiBpdCBh
Y2Nlc3NlcyBhIHJlc291cmNlIGJ1dCBhbHNvDQo+IGFib3V0IHRoZSBjbGllbnQgZW5zdXJpbmcg
dGhhdCBpdCBpbmRlZWQgdGFsa3MgdG8gYSBsZWdpdGltYXRlDQo+IHNlcnZlcj8NCj4gDQo+IERv
ZXMgdGhpcyBzb3VuZCBmYW1pbGlhcj8gSSBhbSBzdXJlIGl0IGRvZXMuIFRoaXMgaXMgZXNzZW50
aWFsbHkgdGhlDQo+IEFDRSBwcm9ibGVtIHN0YXRlbWVudC4gSW4gdGhlIGN1cnJlbnQgY2xpZW50
LXRvLWNsb3VkIG1vZGVsIGFsbCB0aGVzZQ0KPiBwcm9ibGVtcyBhcmUgc29ydCBvZiAic29sdmVk
IiBieSBzaW1wbHkgYXNzdW1pbmcgdGhhdCB0aGUgY2xvdWQNCj4gc2VydmljZSBwcm92aWRlciBh
bHNvIHByb3Zpc2lvbnMgdGhlIElvVCBkZXZpY2UuIEJ1dCBpbiBhIG1vcmUgb3Blbg0KPiBtb2Rl
bCAod2hpY2ggaXMsIHF1aXRlIG5hdHVyYWxseSwgaW1wb3J0YW50IHRvIGhhdmUpIHRoZXNlIHF1
ZXN0aW9ucw0KPiBhcmUgdGhlbiBzb2x2ZWQgZWl0aGVyIHVzaW5nIHBhaXJpbmcgKGluIHRoZSB2
ZXJ5IGxpbWl0ZWQgY2FzZSwgc2VlDQo+IGRlc2NyaXB0aW9uIGluIFNlY3Rpb24gMSBvZiANCj4g
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1hY2Utb3ZlcnZpZXct
MDApIG9yIGJ5DQo+IGludHJvZHVjaW5nIHRoaXMgZmFtb3VzIHRoaXJkIHBhcnR5ICh3aGljaCBp
cyB0aGUgYXV0aG9yaXphdGlvbg0KPiBzZXJ2ZXIgaW4gdGhlIEFDRSBjYXNlKS4NCj4gDQo+IFdo
YXQgZG9lcyB0aGlzIG1lYW4gZm9yIHRoZSBkcmFmdD8NCj4gDQo+IEkgY2FuIGNoZWF0IGEgbGl0
dGxlIGJpdCBieSBnbGFuY2luZyBvdmVyIHRoZSBoYXJkIHByb2JsZW1zIGFuZCBqdXN0DQo+IHN0
YXJ0IHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgY2xpZW50IHdpbGwgc29tZWhvdyBnZXQg
dGhlIHJpZ2h0DQo+IGNyZWRlbnRpYWxzLCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uLCBhY2Nl
c3MgcmlnaHRzLCByZXZvY2F0aW9uDQo+IGluZm9ybWF0aW9uLCBldGMuIGZyb20gc29tZXdoZXJl
LiBIZW5jZSwgdGhpcyBpcyBhIHB1cmUgVExTIGV4Y2hhbmdlDQo+IGFuZCBJIG9ubHkgbmVlZCB0
byBtYWtlIHRoZSBtb2RpZmljYXRpb25zIHN0YXRlZCBhdCB0aGUgYmVnaW5uaW5nIG9mDQo+IG15
IG1haWwuIEkgY291bGQgcmVmZXJlbmNlIHRoZSBvbmdvaW5nIEFDRSB3b3JrLCB3aGljaCB3aWxs
IGF0IGxlYXN0DQo+IGRlYWwgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBxdWVzdGlvbnMuIE9mIGNv
dXJzZSwgdGhhdCB3cml0ZS11cCBpbg0KPiB0aGUgRElDRSBkcmFmdCBieSBpdHNlbGYgaXMgbm90
IGJlIGludGVyb3BlcmFibGUgYXMgYSBzdGFuZGFsb25lDQo+IGl0ZW0uDQo+IA0KPiBIb3cgZG9l
cyB0aGF0IHNvdW5kPw0KPiANCj4gQ2lhbyBIYW5uZXMNCj4gDQo+IA0KPiANCj4gDQoNCg==


From nobody Wed Dec 17 00:03:17 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF811A6F63 for ; Wed, 17 Dec 2014 00:03:16 -0800 (PST)
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 vsXWXHTSLJ5I for ; Wed, 17 Dec 2014 00:03:14 -0800 (PST)
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 A29181A6F65 for ; Wed, 17 Dec 2014 00:03:13 -0800 (PST)
Received: from [192.168.131.138] ([80.92.123.25]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LskKv-1XuRVu0f17-012Fig for ; Wed, 17 Dec 2014 09:03:11 +0100
Message-ID: <549138BE.7090607@gmx.net>
Date: Wed, 17 Dec 2014 09:03:10 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" 
References: 
In-Reply-To: 
OpenPGP: id=4D776BC9
X-Forwarded-Message-Id: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Oc2TpoVHO7K8FnRr2Ndp0HeqNv6bkuoAk"
X-Provags-ID: V03:K0:htxbuzbHibl+XcN17HJWOUvdU7FW3S9dXDUWzmJQL6f9dEnx5et M+gRWtKXutLr5HzEZKs31uckb6+lhzdnCm/9wYKkpZzcBhB8NpG2BCzni7EtuHvrCtm9iZm 8JxGCedCnOpWxNrkEvxSRkLax1K9F5vWDjOd1fTvK9e4T29Z16j4GKJQlS+UcVXJ9JKWoJR FqMoqAYg/42Q9E/5h7Zkg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/ZtuoMUGPmZb2ETpImTzhBALnpvU
Subject: [Dtls-iot] Fwd: Comments on draft-ietf-dice-profile
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, 17 Dec 2014 08:03:16 -0000

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

Ekr provided a review and I have incorporated his feedback into the
document.

Here is the work-in-progress version:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profi=
le/draft-ietf-dice-profile-08.txt

Ciao
Hannes

-------- Forwarded Message --------
Subject: 	Comments on draft-ietf-dice-profile
Resent-To: 	hannes.tschofenig@gmx.net
Date: 	Thu, 4 Dec 2014 10:36:48 -0800
From: 	Eric Rescorla 
To: 	draft-ietf-dice-profile@tools.ietf.org



Hannes,

I took a look at this draft. Some comments below.

OVERALL
This seems generally pretty good.

I would try to be more clear about whats just advice and what's
normative. In particular, it's odd to have "Recommendation: You MUST..."

I wouldn't bother with showing the cookie exchange in any but the first
ladder diagram. Also, maybe make extensions clearer by indenting them
or putting them in parentheses or something.


DETAILS
S 1.
Suggest explaining that "stream" here is a TLS technical term and that
e.g., CTR mode is not a stream cipher in this context.


S 5.1.
   The client indicates which key it uses by including a "PSK identity"
   in the ClientKeyExchange message.  As described in Section 3 clients
   may have multiple pre-shared keys with a single server and to help
   the client in selecting which PSK identity / PSK pair to use, the
   server can provide a "PSK identity hint" in the ServerKeyExchange
   message.  If the hint for PSK key selection is based on the domain
   name of the server then servers SHOULD NOT send the "PSK identity
   hint" in the ServerKeyExchange message.  Hence, servers SHOULD NOT
   send the "PSK identity hint" in the ServerKeyExchange message and
   client MUST ignore the message.  This approach is inline with RFC
   4279 [RFC4279].  Note: The TLS Server Name Indication (SNI) extension
   allows the client to tell a server the name of the server it is
   contacting, which is relevant for hosting environments.  A server
   using the identity hint needs to guide the selection based on a
   received SNI value from the client.

I have read this several times and I'm not sure what it means. Is
it just saying "don't send identity hints" plus some explanation of why?
If so, perhaps a rewrite.


   RFC 4279 requires TLS implementations supporting PSK ciphersuites to
   support arbitrary PSK identities up to 128 octets in length, and
   arbitrary PSKs up to 64 octets in length.  This is a useful
   assumption for TLS stacks used in the desktop and mobile environment
   where management interfaces are used to provision identities and
   keys.  For the IoT environment, however, many devices are not
   equipped with displays and input devices (e.g., keyboards).  Hence,
   keys are distributed as part of hardware modules or are embedded into
   the firmware.  As such, these restrictions are not applicable to this
   profile.

EKR: This is a normative statement, right? Please make it so.


S 5.2.
   1.2 and utilizes an eight-octet authentication tag.  The use of a
   Diffie-Hellman key exchange adds perfect forward secrecy (PFS).  More

"Elliptic Curve Diffie-Hellman". Also perhaps "provides" rather
than adds.


S 5.3.
   contains the root certificates.  The use of the Trust Anchor
   Management Protocol (TAMP) [RFC5934] is, however, not envisioned.
   Instead IoT devices using this profile MUST rely a software update
   mechanism to provision these trust anchors.

I don't really understand this last statement.


S 6.
   insufficient_security:  This error message indicates that the server
      requires ciphers to be more secure.  This document does, however,
      specify the only acceptable ciphersuites and client
      implementations must support them.

I don't really believe this because of the usual versioning reasons.


S 8.
   This DTLS client profile does not include DTLS layer compression.

Maybe say "MUST NOT use"


S 13.
   Recommendation: For IoT deployments where clients talk to a fixed,
   pre-configured set of servers and where a software update mechanism
   is available this extension is not recommended.  Environments where
   the client needs to interact with dynamically discovered DTLS servers
   this extension may be useful to reduce the communication overhead.
   Note, however, in that case the TLS cached info extension may help to
   reduce the communication overhead for everything but the first
   protocol interaction.

this is pretty fuzzy


S 14.
   Recommendation: Since this profile only supports AEAD ciphersuites
   this extension is not applicable.

Why is this not a MUST NOT?


S 17.
   Recommendation: Client implementations SHOULD implement this
   extension support this extension even though the ciphersuites
   recommended by this profile are not vulnerable this attack.

You should double-check this against the triple handshake paper.

-Ekr





--Oc2TpoVHO7K8FnRr2Ndp0HeqNv6bkuoAk
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

iQEcBAEBCgAGBQJUkTi/AAoJEGhJURNOOiAtWGgH/jT1nBiE841chm8cBEmIRowH
c/Oa+QT2ZzjYgT/6BSMeWcB13VDf6Lb6kxHlRYqpsUNJv5HeCXQ8b1HdUmrS9cgx
ed5TTnZaMAs8lIyhvLDqmmMwsX8/Cr7kKV1YXAZ8kz75AHH66XIHISSt0Syobo2m
ygtzMzaEKhtyOOH/R4LtVdppeDwS8EnNYVGlpxqxTuOVmlxeD72PH5O9mVtAxNyC
RkBkMTrrzKbYlMDyAWXB2kBGmdIA92xEm4SjqH5v7yBdhyWy6GHtnv6x4giANaRr
KKIfdfFtIiyv0pST6DI8u6tySQ8+7+pxe8wk67xa+kztnODckWJUaTlbz36ZV/g=
=U5E4
-----END PGP SIGNATURE-----

--Oc2TpoVHO7K8FnRr2Ndp0HeqNv6bkuoAk--


From nobody Thu Dec 18 03:28:02 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7CD1A6F2E for ; Thu, 18 Dec 2014 03:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ndgQB_zdhoPE for ; Thu, 18 Dec 2014 03:27:57 -0800 (PST)
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 2426C1A6EDB for ; Thu, 18 Dec 2014 03:27:56 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A240F9EDF5FDE for ; Thu, 18 Dec 2014 11:27:52 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sBIBRs3l012159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Dec 2014 12:27:55 +0100
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.139]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 12:27:47 +0100
From: "FOSSATI, Thomas (Thomas)" 
To: "dtls-iot@ietf.org" 
Thread-Topic: Fragmentation, overlapping, and PMTU handling (ticket #23)
Thread-Index: AQHQGrWmi5ODw2nSoU2e1uR3EuUk9Q==
Date: Thu, 18 Dec 2014 11:27:47 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_D0B865F91E088thomasfossatialcatellucentcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/lkhOSGX6aQPTXX4fLYhoo9cAxws
Subject: [Dtls-iot] Fragmentation, overlapping, and PMTU handling (ticket #23)
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, 18 Dec 2014 11:28:00 -0000

--_000_D0B865F91E088thomasfossatialcatellucentcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi all,

we have have been pondering about how to turn the comments received so far =
into a set of recommendations on how to avoid fragments overlapping.

Reading through the DTLS spec there are two points re: fragmentation, overl=
apping and PMTU handling:

  1.  https://tools.ietf.org/html/rfc6347#section-4.2.3 "Handshake Message =
Fragmentation and Reassembly"
     *   "When transmitting the handshake message, the sender divides the m=
essage into a series of N contiguous data ranges. [...] The ranges SHOULD N=
OT overlap."
     *   "DTLS implementations MUST be able to handle overlapping fragment =
ranges. This allows senders to retransmit handshake messages with smaller f=
ragment sizes if the PMTU estimate changes."
  2.  https://tools.ietf.org/html/rfc6347#section-4.1.1.1 "PMTU Issues"
     *    "[...] the handshake protocol PMTU handling places a premium on r=
apid completion over accurate PMTU discovery".

Combining the two together: it looks like the problematic 1.2 (that Matthia=
s would like to drop) exists only to allow the "casual" PMTU discovery duri=
ng handshake hinted in 2.1.

Maybe one simple thing that we could recommend to reduce the likelihood of =
producing different fragment sizes (and consequent overlaps) is:

  *   for clients, (handshake initiators), to perform PMTU discovery toward=
s the server accurately *before* handshake starts, and not rely on any a-pr=
iori guess (unless the network path characteristics are known OOB);
  *   for servers, to mirror the fragment size selected by their clients.

We don't think the document should suggest a one-size-fits-all value (i.e. =
Robert's suggestion about using the typical 1280 bytes MTU), because if you=
 have to go through a 6lowPAN or other narrow band bearers then it's going =
to be problematic.

We are aware that this "know your PMTU" suggestion is a bit lame (but that'=
s it, we really can't change DTLS here), so if you have better ideas please=
 shout =97 maybe even saying that the topic should be dropped due to lack o=
f useful guidance and moved completely to LWIG.

(We plan to submit -08 tomorrow.)

Cheers, t

--_000_D0B865F91E088thomasfossatialcatellucentcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <26921B449EE3BD42AFB40FD23CF77D1A@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable







Hi all,







we have have been pondering about how to turn the comments received so=
 far into a set of recommendations on how to avoid fragments overlapping.






Reading through the DTLS spec there are two points re: fragmentation, =
overlapping and PMTU handling:


    

  1. https://tools.ietf.org/html/rfc6347#section-4.2.3 "Handshake Messa=
ge Fragmentation and Reassembly"

      

    1. "When transmitting the handshake message, the sender divides the m=
essage into a series of N contiguous data ranges. [...] The ranges SHOULD N=
OT overlap."
    2. "DTLS implementations MUST be able to handle=
 overlapping fragment ranges. This allows senders to retransmit handshake m=
essages with smaller fragment sizes if the PMTU estimate changes."
    

  2. https://tools.ietf.org/html/rfc6347#section-4.1.1.1 "PMTU Iss=
ues"

      

    1.  "[...] the handshake protocol PMTU handling places a premium=
 on rapid completion over accurate PMTU discovery".
    



Combining the two together: it looks like the problematic 1.2 (that Ma=
tthias would like to drop) exists only to allow the "casual" PMTU=
 discovery during handshake hinted in 2.1.







Maybe one simple thing that we could recommend to reduce the likelihoo=
d of producing different fragment sizes (and consequent overlaps) is:


    

  • for clients, (handshake initiators), to perform PMTU discovery towards =
the server accurately *before* handshake starts, and not rely on any a-prio=
ri guess (unless the network path characteristics are known OOB);
  • f=
or servers, to mirror the fragment size selected by their clients.
    • 

    We don't think the document should suggest a one-size-fits-all value (=
i.e. Robert's suggestion about using the typical 1280 bytes MTU), because i=
f you have to go through a 6lowPAN or other narrow band bearers then it's g=
oing to be problematic.
    


    

    

    We are aware that this "know your PMTU" suggestion is a bit =
lame (but that's it, we really can't change DTLS here), so if you have bett=
er ideas please shout =97 maybe even saying that the topic should be droppe=
d due to lack of useful guidance and moved completely
 to LWIG.
    


    

    

    (We plan to submit -08 tomorrow.)
    


    

    

    Cheers, t
    



--_000_D0B865F91E088thomasfossatialcatellucentcom_--


From nobody Thu Dec 18 03:49:20 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC531A6FB0 for ; Thu, 18 Dec 2014 03:49:15 -0800 (PST)
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 n_BD3iRWlaqY for ; Thu, 18 Dec 2014 03:49:12 -0800 (PST)
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 D23C81A6F53 for ; Thu, 18 Dec 2014 03:49:10 -0800 (PST)
Received: from [192.168.131.138] ([80.92.123.25]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZ7bs-1YMWm81cVw-00KxFc for ; Thu, 18 Dec 2014 12:49:09 +0100
Message-ID: <5492BF33.6040209@gmx.net>
Date: Thu, 18 Dec 2014 12:49:07 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.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="HNc198OuNiB6NJgmdrxlUOOWnRWOQAmtU"
X-Provags-ID: V03:K0:LWm8yVFZjs+ZVsq2x8OtMkFDyd5f8dz2d0WIiVPyJ/C00HvlpA+ ooK1fkgSyZTvdLa2UA31wf5K5zXcTa+fC0MgEFugN2+yPx8i3MpAKHo9PY8pOX0cel6vPS2 uMJbqqVT+uA3s0MwE9aGFy8a/sUj0i7e2OoR74OISwgr2hfYQtacRPP+bwpsJDix9UGwRVg +ub76A/EoafZIgYunGoXQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/5WOivtKvu6nnrQQjKUzbf295WOA
Subject: [Dtls-iot] Constrained Servers (ticket#16)
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, 18 Dec 2014 11:49:16 -0000

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

Hi all,

I have been trying to resolve the comments related to the constrained
server discussion and the changes are as follows (see latest document
version at
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profi=
le/draft-ietf-dice-profile-08.txt):

- Expanded the text for the constrained client and moved text around
(see Section 4.1).

- Added new text for the constrained server case to Section 4.2 (see
also below) based on the recent email exchange (link:
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00529.html).

- Updated Section 9 "Session Resumption", Section 14 "Random Number
Generation", and Section 16 "Server Name Indication). I copied the
relevant section into this email.

Ciao
Hannes


----------

4.2.  Constrained TLS/DTLS Servers

   Section 4.1 illustrates deployment models where the TLS/DTLS client
   is constrained and efforts need to be taken to improve memory
   utilization, bandwidth consumption, reduce performance impacts, etc.
   In this section we look at cases where constrained devices run TLS/
   DTLS servers to secure access to an application layer protocol
   server, like a CoAP or HTTP server.  Running server functionality on
   a constrained node is typically more demanding since servers have to
   listen and wait for incoming requests.  Therefore, they will have
   fewer possibilities to enter sleeping cycles.  Nevertheless, there
   are legitimate reasons to deploy servers as constrained devices.

   A deployment with constrained servers has to overcome several
   challenges.  Later we will explain how these challenges has been
   solved using CoAP as an example.  Other protocols may offer similar
   capabilities.  While the requirements for the TLS/DTLS protocol
   profile change only slightly when run on a constrained server (in
   comparison to running it on a constrained client) several other eco-
   system factor will impact deployment.

   The challenges are:

   Discovery and Reachability:

      Before initiating a connection to a constrained server a client
      first needs to discover that server and, once discovered, it needs
      to maintain reachability with that device.

      In CoAP the discovery of resources offered by servers is
      accomplished by sending a unicast or multicast CoAP GET to a well-
      known URI.  The CORE Link format specification [RFC6690] describes
      the use case (see Section 1.2.1), and reserves the URI (see
      Section 7.1).  Section 7 of the CoAP specification [RFC7252]
      describes the discovery procedure.  RFC 7390 [RFC7390] describes
      use case for discovering CoAP servers using multicast (see
      Section 3.3), and specifies the protocol processing rules for CoAP
      group communications (see Section 2.7).

   Authentication:

      The next challenge concerns the provisioning of authentication
      credentials to the clients as well as servers.  In Section 4.1 we
      assumed that credentials (and other configuration information) are
      provisioned to the device and that those can be used with the
      authorization servers.  Of course, this leads to a very static
      relationship between the clients and their server-side
      infrastructure but poses fewer challenges from a deployment point
      of view, as described in Section 2 of
      [I-D.iab-smart-object-architecture] these different communication
      patterns.  In any case, engineers and product designers have to
      determine how the relevant credentials are distributed to the
      respective parties.  For example, shared secrets may need to be
      provisioned to clients and the constrained servers for subsequent
      use of TLS/DTLS PSK.  In other deployments, certificates, private
      keys, and trust anchors for use with certificate-based
      authentication may need to be utilized.

      Practical solutions either use pairing (also called imprinting) or
      a trusted third party.  With pairing two devices execute a special
      protocol exchange that is unauthenticated to establish an shared
      key (for example using an unauthenticated Diffie-Hellman exchange)
      key.  To avoid man-in-the-middle attacks an out-of-band channel is
      used to verify that nobody has tampered with the exchanged
      protocol messages.  This out-of-band channel can come in many
      forms, including:

      *  Human involvement by comparing hashed keys, entering passkeys,
         scanning QR codes

      *  The use of alternative wireless communication channels (e.g.,
         infra-red communication in addition to WiFi)

      *  Proximity-based information

      More details about these different pairing/imprinting techniques
      can be found in the smart object security workshop report
      [RFC7397] and various position papers submitted to that topic,
      such as [ImprintingSurvey].  The use of a trusted third party
      follows a different approach and is subject to ongoing
      standardization efforts in the 'Authentication and Authorization
      for Constrained Environments (ACE)' working group.

   Authorization

      The last challenge is the ability for the constrained server to
      make an authorization decision when clients access protected
      resources.  Pre-provisioning access control information to
      constrained servers may be one option but works only in a small
      scale, less dynamic environment.  For a more fine-grained and
      dynamic access control the reader is referred to the ongoing work
      in the ACE working group.


9.  Session Resumption

   Session resumption is a feature of the core TLS/DTLS specifications
   that allows a client to continue with an earlier established session
   state.  The resulting exchange is shown in Figure 8.  In addition,
   the server may choose not to do a cookie exchange when a session is
   resumed.  Still, clients have to be prepared to do a cookie exchange
   with every handshake.  The cookie exchange is not shown in the
   figure.


         Client                                               Server
         ------                                               ------

         ClientHello                   -------->
                                                          ServerHello
                                                   [ChangeCipherSpec]
                                       <--------             Finished
         [ChangeCipherSpec]
         Finished                      -------->
         Application Data              <------->     Application Data


                    Figure 8: DTLS Session Resumption.

   Constrained clients MUST implement session resumption to improve the
   performance of the handshake.  This will lead to a reduced number of
   message exchanges, lower computational overhead (since only symmetric
   cryptography is used during a session resumption exchange), and
   session resumption requires less bandwidth.

   For cases where the server is constrained (but not the client) the
   client MUST implement RFC 5077 [RFC5077].  RFC 5077 specifies a
   version of TLS/DTLS session resumption that does not require per-
   session state information to be maintained by the constrained server.
   This is accomplished by using a ticket-based approach.

   If both the client and the server are constrained devices both
   devices SHOULD implement RFC 5077 and MUST implement basic session
   resumption.


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.  Special care has to
   be paid 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.

   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.

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

   IoT devices using TLS/DTLS MUST offer ways to generate quality random
   numbers.  Guidelines and requirements for random number generation
   can be found in RFC 4086 [RFC4086].


16.  Server Name Indication (SNI)

   The Server Name Indication extension defined in [RFC6066] defines a
   mechanism for a client to tell a TLS/DTLS server the name of the
   server it wants to contact.  This is a useful extension for many
   hosting environments where multiple virtual servers are run on single
   IP address.

   This specification RECOMMENDs the implementation of RFC 6066 unless
   it is known that a TLS/DTLS client does not interact with a server in
   a hosting environment.




--HNc198OuNiB6NJgmdrxlUOOWnRWOQAmtU
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

iQEcBAEBCgAGBQJUkr8zAAoJEGhJURNOOiAtnp4IAJgf6AvTg2EZOPPZXYLMEDDC
7RzwoOSSvkZE4zS0deKX3xxBy8mAR9jjALLXr2XNCBReOvWnfUyxHBFhgiNRgLqD
lLbFwBYkjtkui48JKHrZw+FZIdfntCBhWcVqrVGmlq/GYdLt0eG25GJtueF0D6be
sPEDpUn4RmaKezlwtyOtuLxaLNjbHOe82F9b55or4R3bynleRQOTb3HCOD8FqLHo
xfyaajVGkAB9Roq6ucl5eeFqRFJy6pnkBOvOkjr3exZ8hSlGOsfmS15ufJ7eezxF
VQOxPDfQLA0IzG3JKtKn0ijn4ufXQhvescDEn4KUcbUlQ1PwE2Ne6W9v5WqDeog=
=dyTH
-----END PGP SIGNATURE-----

--HNc198OuNiB6NJgmdrxlUOOWnRWOQAmtU--


From nobody Thu Dec 18 06:49:26 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28351A8A52 for ; Thu, 18 Dec 2014 06:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.245
X-Spam-Level: 
X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFEYuKJbmYiB for ; Thu, 18 Dec 2014 06:49:22 -0800 (PST)
Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAA01A8A4C for ; Thu, 18 Dec 2014 06:49:22 -0800 (PST)
X-ASG-Debug-ID: 1418914160-06daaa5125b7880001-roOjxa
Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id FIgDCqxBcBRW1Gyp for ; Thu, 18 Dec 2014 09:49:20 -0500 (EST)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 18 Dec 2014 09:49:20 -0500
Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 18 Dec 2014 09:49:19 -0500
Received: from NALENITE.InterDigital.com (10.2.64.253) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 18 Dec 2014 09:49:19 -0500
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0210.002; Thu, 18 Dec 2014 09:49:18 -0500
From: "Rahman, Akbar" 
To: Hannes Tschofenig , "dtls-iot@ietf.org" 
Thread-Topic: [Dtls-iot] Constrained Servers (ticket#16)
X-ASG-Orig-Subj: RE: [Dtls-iot] Constrained Servers (ticket#16)
Thread-Index: AQHQGriqa7EMqhoG90+v9RfrcfkkiJyVbQQg
Date: Thu, 18 Dec 2014 14:49:18 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F08F4BC@NABESITE.InterDigital.com>
References: <5492BF33.6040209@gmx.net>
In-Reply-To: <5492BF33.6040209@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.17]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Dec 2014 14:49:19.0813 (UTC) FILETIME=[CDDE4F50:01D01AD1]
X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27]
X-Barracuda-Start-Time: 1418914160
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.13058 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/UmoUy2arfxwn1lE4MPqg3M3sJ0A
Subject: Re: [Dtls-iot] Constrained Servers (ticket#16)
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, 18 Dec 2014 14:49:25 -0000

SGkgSGFubmVzLA0KDQoNCkkgdG9vayBhIHF1aWNrIHNjYW4gb2YgaXQgYW5kIGl0IGxvb2tzIHZl
cnkgZ29vZC4gIFRoZSBvbmx5IG1pbm9yIHN1Z2dlc3Rpb24gdGhhdCBJIGhhdmUgaXMgaWYgeW91
IGNvdWxkIGluY2x1ZGUgYSBzaW1wbGUgZmlndXJlIGluIHNlY3Rpb24gNC4yIChzaW1pbGFyIHRv
IHlvdXIgRmlndXJlIDEgaW4gc2VjdGlvbiA0LjEpLiAgQnV0IHRoaXMgaXMgb25seSBhIE5pY2Ug
VG8gSGF2ZSBzdWdnZXN0aW9uIGFuZCBub3QgYSBNdXN0IEhhdmUuDQoNCg0KQmVzdCBSZWdhcmRz
LA0KDQoNCkFrYmFyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkdGxzLWlv
dCBbbWFpbHRvOmR0bHMtaW90LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMg
VHNjaG9mZW5pZw0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDE4LCAyMDE0IDY6NDkgQU0NClRv
OiBkdGxzLWlvdEBpZXRmLm9yZw0KU3ViamVjdDogW0R0bHMtaW90XSBDb25zdHJhaW5lZCBTZXJ2
ZXJzICh0aWNrZXQjMTYpDQoNCkhpIGFsbCwNCg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIHJlc29s
dmUgdGhlIGNvbW1lbnRzIHJlbGF0ZWQgdG8gdGhlIGNvbnN0cmFpbmVkIHNlcnZlciBkaXNjdXNz
aW9uIGFuZCB0aGUgY2hhbmdlcyBhcmUgYXMgZm9sbG93cyAoc2VlIGxhdGVzdCBkb2N1bWVudCB2
ZXJzaW9uIGF0DQpodHRwczovL2dpdGh1Yi5jb20vaGFubmVzdHNjaG9mZW5pZy90c2Nob2Zlbmln
LWlkcy9ibG9iL21hc3Rlci9kaWNlLXByb2ZpbGUvZHJhZnQtaWV0Zi1kaWNlLXByb2ZpbGUtMDgu
dHh0KToNCg0KLSBFeHBhbmRlZCB0aGUgdGV4dCBmb3IgdGhlIGNvbnN0cmFpbmVkIGNsaWVudCBh
bmQgbW92ZWQgdGV4dCBhcm91bmQgKHNlZSBTZWN0aW9uIDQuMSkuDQoNCi0gQWRkZWQgbmV3IHRl
eHQgZm9yIHRoZSBjb25zdHJhaW5lZCBzZXJ2ZXIgY2FzZSB0byBTZWN0aW9uIDQuMiAoc2VlIGFs
c28gYmVsb3cpIGJhc2VkIG9uIHRoZSByZWNlbnQgZW1haWwgZXhjaGFuZ2UgKGxpbms6DQpodHRw
Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZHRscy1pb3QvY3VycmVudC9tc2cwMDUy
OS5odG1sKS4NCg0KLSBVcGRhdGVkIFNlY3Rpb24gOSAiU2Vzc2lvbiBSZXN1bXB0aW9uIiwgU2Vj
dGlvbiAxNCAiUmFuZG9tIE51bWJlciBHZW5lcmF0aW9uIiwgYW5kIFNlY3Rpb24gMTYgIlNlcnZl
ciBOYW1lIEluZGljYXRpb24pLiBJIGNvcGllZCB0aGUgcmVsZXZhbnQgc2VjdGlvbiBpbnRvIHRo
aXMgZW1haWwuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCi0tLS0tLS0tLS0NCg0KNC4yLiAgQ29uc3Ry
YWluZWQgVExTL0RUTFMgU2VydmVycw0KDQogICBTZWN0aW9uIDQuMSBpbGx1c3RyYXRlcyBkZXBs
b3ltZW50IG1vZGVscyB3aGVyZSB0aGUgVExTL0RUTFMgY2xpZW50DQogICBpcyBjb25zdHJhaW5l
ZCBhbmQgZWZmb3J0cyBuZWVkIHRvIGJlIHRha2VuIHRvIGltcHJvdmUgbWVtb3J5DQogICB1dGls
aXphdGlvbiwgYmFuZHdpZHRoIGNvbnN1bXB0aW9uLCByZWR1Y2UgcGVyZm9ybWFuY2UgaW1wYWN0
cywgZXRjLg0KICAgSW4gdGhpcyBzZWN0aW9uIHdlIGxvb2sgYXQgY2FzZXMgd2hlcmUgY29uc3Ry
YWluZWQgZGV2aWNlcyBydW4gVExTLw0KICAgRFRMUyBzZXJ2ZXJzIHRvIHNlY3VyZSBhY2Nlc3Mg
dG8gYW4gYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wNCiAgIHNlcnZlciwgbGlrZSBhIENvQVAg
b3IgSFRUUCBzZXJ2ZXIuICBSdW5uaW5nIHNlcnZlciBmdW5jdGlvbmFsaXR5IG9uDQogICBhIGNv
bnN0cmFpbmVkIG5vZGUgaXMgdHlwaWNhbGx5IG1vcmUgZGVtYW5kaW5nIHNpbmNlIHNlcnZlcnMg
aGF2ZSB0bw0KICAgbGlzdGVuIGFuZCB3YWl0IGZvciBpbmNvbWluZyByZXF1ZXN0cy4gIFRoZXJl
Zm9yZSwgdGhleSB3aWxsIGhhdmUNCiAgIGZld2VyIHBvc3NpYmlsaXRpZXMgdG8gZW50ZXIgc2xl
ZXBpbmcgY3ljbGVzLiAgTmV2ZXJ0aGVsZXNzLCB0aGVyZQ0KICAgYXJlIGxlZ2l0aW1hdGUgcmVh
c29ucyB0byBkZXBsb3kgc2VydmVycyBhcyBjb25zdHJhaW5lZCBkZXZpY2VzLg0KDQogICBBIGRl
cGxveW1lbnQgd2l0aCBjb25zdHJhaW5lZCBzZXJ2ZXJzIGhhcyB0byBvdmVyY29tZSBzZXZlcmFs
DQogICBjaGFsbGVuZ2VzLiAgTGF0ZXIgd2Ugd2lsbCBleHBsYWluIGhvdyB0aGVzZSBjaGFsbGVu
Z2VzIGhhcyBiZWVuDQogICBzb2x2ZWQgdXNpbmcgQ29BUCBhcyBhbiBleGFtcGxlLiAgT3RoZXIg
cHJvdG9jb2xzIG1heSBvZmZlciBzaW1pbGFyDQogICBjYXBhYmlsaXRpZXMuICBXaGlsZSB0aGUg
cmVxdWlyZW1lbnRzIGZvciB0aGUgVExTL0RUTFMgcHJvdG9jb2wNCiAgIHByb2ZpbGUgY2hhbmdl
IG9ubHkgc2xpZ2h0bHkgd2hlbiBydW4gb24gYSBjb25zdHJhaW5lZCBzZXJ2ZXIgKGluDQogICBj
b21wYXJpc29uIHRvIHJ1bm5pbmcgaXQgb24gYSBjb25zdHJhaW5lZCBjbGllbnQpIHNldmVyYWwg
b3RoZXIgZWNvLQ0KICAgc3lzdGVtIGZhY3RvciB3aWxsIGltcGFjdCBkZXBsb3ltZW50Lg0KDQog
ICBUaGUgY2hhbGxlbmdlcyBhcmU6DQoNCiAgIERpc2NvdmVyeSBhbmQgUmVhY2hhYmlsaXR5Og0K
DQogICAgICBCZWZvcmUgaW5pdGlhdGluZyBhIGNvbm5lY3Rpb24gdG8gYSBjb25zdHJhaW5lZCBz
ZXJ2ZXIgYSBjbGllbnQNCiAgICAgIGZpcnN0IG5lZWRzIHRvIGRpc2NvdmVyIHRoYXQgc2VydmVy
IGFuZCwgb25jZSBkaXNjb3ZlcmVkLCBpdCBuZWVkcw0KICAgICAgdG8gbWFpbnRhaW4gcmVhY2hh
YmlsaXR5IHdpdGggdGhhdCBkZXZpY2UuDQoNCiAgICAgIEluIENvQVAgdGhlIGRpc2NvdmVyeSBv
ZiByZXNvdXJjZXMgb2ZmZXJlZCBieSBzZXJ2ZXJzIGlzDQogICAgICBhY2NvbXBsaXNoZWQgYnkg
c2VuZGluZyBhIHVuaWNhc3Qgb3IgbXVsdGljYXN0IENvQVAgR0VUIHRvIGEgd2VsbC0NCiAgICAg
IGtub3duIFVSSS4gIFRoZSBDT1JFIExpbmsgZm9ybWF0IHNwZWNpZmljYXRpb24gW1JGQzY2OTBd
IGRlc2NyaWJlcw0KICAgICAgdGhlIHVzZSBjYXNlIChzZWUgU2VjdGlvbiAxLjIuMSksIGFuZCBy
ZXNlcnZlcyB0aGUgVVJJIChzZWUNCiAgICAgIFNlY3Rpb24gNy4xKS4gIFNlY3Rpb24gNyBvZiB0
aGUgQ29BUCBzcGVjaWZpY2F0aW9uIFtSRkM3MjUyXQ0KICAgICAgZGVzY3JpYmVzIHRoZSBkaXNj
b3ZlcnkgcHJvY2VkdXJlLiAgUkZDIDczOTAgW1JGQzczOTBdIGRlc2NyaWJlcw0KICAgICAgdXNl
IGNhc2UgZm9yIGRpc2NvdmVyaW5nIENvQVAgc2VydmVycyB1c2luZyBtdWx0aWNhc3QgKHNlZQ0K
ICAgICAgU2VjdGlvbiAzLjMpLCBhbmQgc3BlY2lmaWVzIHRoZSBwcm90b2NvbCBwcm9jZXNzaW5n
IHJ1bGVzIGZvciBDb0FQDQogICAgICBncm91cCBjb21tdW5pY2F0aW9ucyAoc2VlIFNlY3Rpb24g
Mi43KS4NCg0KICAgQXV0aGVudGljYXRpb246DQoNCiAgICAgIFRoZSBuZXh0IGNoYWxsZW5nZSBj
b25jZXJucyB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1dGhlbnRpY2F0aW9uDQogICAgICBjcmVkZW50
aWFscyB0byB0aGUgY2xpZW50cyBhcyB3ZWxsIGFzIHNlcnZlcnMuICBJbiBTZWN0aW9uIDQuMSB3
ZQ0KICAgICAgYXNzdW1lZCB0aGF0IGNyZWRlbnRpYWxzIChhbmQgb3RoZXIgY29uZmlndXJhdGlv
biBpbmZvcm1hdGlvbikgYXJlDQogICAgICBwcm92aXNpb25lZCB0byB0aGUgZGV2aWNlIGFuZCB0
aGF0IHRob3NlIGNhbiBiZSB1c2VkIHdpdGggdGhlDQogICAgICBhdXRob3JpemF0aW9uIHNlcnZl
cnMuICBPZiBjb3Vyc2UsIHRoaXMgbGVhZHMgdG8gYSB2ZXJ5IHN0YXRpYw0KICAgICAgcmVsYXRp
b25zaGlwIGJldHdlZW4gdGhlIGNsaWVudHMgYW5kIHRoZWlyIHNlcnZlci1zaWRlDQogICAgICBp
bmZyYXN0cnVjdHVyZSBidXQgcG9zZXMgZmV3ZXIgY2hhbGxlbmdlcyBmcm9tIGEgZGVwbG95bWVu
dCBwb2ludA0KICAgICAgb2YgdmlldywgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMiBvZg0KICAg
ICAgW0ktRC5pYWItc21hcnQtb2JqZWN0LWFyY2hpdGVjdHVyZV0gdGhlc2UgZGlmZmVyZW50IGNv
bW11bmljYXRpb24NCiAgICAgIHBhdHRlcm5zLiAgSW4gYW55IGNhc2UsIGVuZ2luZWVycyBhbmQg
cHJvZHVjdCBkZXNpZ25lcnMgaGF2ZSB0bw0KICAgICAgZGV0ZXJtaW5lIGhvdyB0aGUgcmVsZXZh
bnQgY3JlZGVudGlhbHMgYXJlIGRpc3RyaWJ1dGVkIHRvIHRoZQ0KICAgICAgcmVzcGVjdGl2ZSBw
YXJ0aWVzLiAgRm9yIGV4YW1wbGUsIHNoYXJlZCBzZWNyZXRzIG1heSBuZWVkIHRvIGJlDQogICAg
ICBwcm92aXNpb25lZCB0byBjbGllbnRzIGFuZCB0aGUgY29uc3RyYWluZWQgc2VydmVycyBmb3Ig
c3Vic2VxdWVudA0KICAgICAgdXNlIG9mIFRMUy9EVExTIFBTSy4gIEluIG90aGVyIGRlcGxveW1l
bnRzLCBjZXJ0aWZpY2F0ZXMsIHByaXZhdGUNCiAgICAgIGtleXMsIGFuZCB0cnVzdCBhbmNob3Jz
IGZvciB1c2Ugd2l0aCBjZXJ0aWZpY2F0ZS1iYXNlZA0KICAgICAgYXV0aGVudGljYXRpb24gbWF5
IG5lZWQgdG8gYmUgdXRpbGl6ZWQuDQoNCiAgICAgIFByYWN0aWNhbCBzb2x1dGlvbnMgZWl0aGVy
IHVzZSBwYWlyaW5nIChhbHNvIGNhbGxlZCBpbXByaW50aW5nKSBvcg0KICAgICAgYSB0cnVzdGVk
IHRoaXJkIHBhcnR5LiAgV2l0aCBwYWlyaW5nIHR3byBkZXZpY2VzIGV4ZWN1dGUgYSBzcGVjaWFs
DQogICAgICBwcm90b2NvbCBleGNoYW5nZSB0aGF0IGlzIHVuYXV0aGVudGljYXRlZCB0byBlc3Rh
Ymxpc2ggYW4gc2hhcmVkDQogICAgICBrZXkgKGZvciBleGFtcGxlIHVzaW5nIGFuIHVuYXV0aGVu
dGljYXRlZCBEaWZmaWUtSGVsbG1hbiBleGNoYW5nZSkNCiAgICAgIGtleS4gIFRvIGF2b2lkIG1h
bi1pbi10aGUtbWlkZGxlIGF0dGFja3MgYW4gb3V0LW9mLWJhbmQgY2hhbm5lbCBpcw0KICAgICAg
dXNlZCB0byB2ZXJpZnkgdGhhdCBub2JvZHkgaGFzIHRhbXBlcmVkIHdpdGggdGhlIGV4Y2hhbmdl
ZA0KICAgICAgcHJvdG9jb2wgbWVzc2FnZXMuICBUaGlzIG91dC1vZi1iYW5kIGNoYW5uZWwgY2Fu
IGNvbWUgaW4gbWFueQ0KICAgICAgZm9ybXMsIGluY2x1ZGluZzoNCg0KICAgICAgKiAgSHVtYW4g
aW52b2x2ZW1lbnQgYnkgY29tcGFyaW5nIGhhc2hlZCBrZXlzLCBlbnRlcmluZyBwYXNza2V5cywN
CiAgICAgICAgIHNjYW5uaW5nIFFSIGNvZGVzDQoNCiAgICAgICogIFRoZSB1c2Ugb2YgYWx0ZXJu
YXRpdmUgd2lyZWxlc3MgY29tbXVuaWNhdGlvbiBjaGFubmVscyAoZS5nLiwNCiAgICAgICAgIGlu
ZnJhLXJlZCBjb21tdW5pY2F0aW9uIGluIGFkZGl0aW9uIHRvIFdpRmkpDQoNCiAgICAgICogIFBy
b3hpbWl0eS1iYXNlZCBpbmZvcm1hdGlvbg0KDQogICAgICBNb3JlIGRldGFpbHMgYWJvdXQgdGhl
c2UgZGlmZmVyZW50IHBhaXJpbmcvaW1wcmludGluZyB0ZWNobmlxdWVzDQogICAgICBjYW4gYmUg
Zm91bmQgaW4gdGhlIHNtYXJ0IG9iamVjdCBzZWN1cml0eSB3b3Jrc2hvcCByZXBvcnQNCiAgICAg
IFtSRkM3Mzk3XSBhbmQgdmFyaW91cyBwb3NpdGlvbiBwYXBlcnMgc3VibWl0dGVkIHRvIHRoYXQg
dG9waWMsDQogICAgICBzdWNoIGFzIFtJbXByaW50aW5nU3VydmV5XS4gIFRoZSB1c2Ugb2YgYSB0
cnVzdGVkIHRoaXJkIHBhcnR5DQogICAgICBmb2xsb3dzIGEgZGlmZmVyZW50IGFwcHJvYWNoIGFu
ZCBpcyBzdWJqZWN0IHRvIG9uZ29pbmcNCiAgICAgIHN0YW5kYXJkaXphdGlvbiBlZmZvcnRzIGlu
IHRoZSAnQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24NCiAgICAgIGZvciBDb25zdHJh
aW5lZCBFbnZpcm9ubWVudHMgKEFDRSknIHdvcmtpbmcgZ3JvdXAuDQoNCiAgIEF1dGhvcml6YXRp
b24NCg0KICAgICAgVGhlIGxhc3QgY2hhbGxlbmdlIGlzIHRoZSBhYmlsaXR5IGZvciB0aGUgY29u
c3RyYWluZWQgc2VydmVyIHRvDQogICAgICBtYWtlIGFuIGF1dGhvcml6YXRpb24gZGVjaXNpb24g
d2hlbiBjbGllbnRzIGFjY2VzcyBwcm90ZWN0ZWQNCiAgICAgIHJlc291cmNlcy4gIFByZS1wcm92
aXNpb25pbmcgYWNjZXNzIGNvbnRyb2wgaW5mb3JtYXRpb24gdG8NCiAgICAgIGNvbnN0cmFpbmVk
IHNlcnZlcnMgbWF5IGJlIG9uZSBvcHRpb24gYnV0IHdvcmtzIG9ubHkgaW4gYSBzbWFsbA0KICAg
ICAgc2NhbGUsIGxlc3MgZHluYW1pYyBlbnZpcm9ubWVudC4gIEZvciBhIG1vcmUgZmluZS1ncmFp
bmVkIGFuZA0KICAgICAgZHluYW1pYyBhY2Nlc3MgY29udHJvbCB0aGUgcmVhZGVyIGlzIHJlZmVy
cmVkIHRvIHRoZSBvbmdvaW5nIHdvcmsNCiAgICAgIGluIHRoZSBBQ0Ugd29ya2luZyBncm91cC4N
Cg0KDQo5LiAgU2Vzc2lvbiBSZXN1bXB0aW9uDQoNCiAgIFNlc3Npb24gcmVzdW1wdGlvbiBpcyBh
IGZlYXR1cmUgb2YgdGhlIGNvcmUgVExTL0RUTFMgc3BlY2lmaWNhdGlvbnMNCiAgIHRoYXQgYWxs
b3dzIGEgY2xpZW50IHRvIGNvbnRpbnVlIHdpdGggYW4gZWFybGllciBlc3RhYmxpc2hlZCBzZXNz
aW9uDQogICBzdGF0ZS4gIFRoZSByZXN1bHRpbmcgZXhjaGFuZ2UgaXMgc2hvd24gaW4gRmlndXJl
IDguICBJbiBhZGRpdGlvbiwNCiAgIHRoZSBzZXJ2ZXIgbWF5IGNob29zZSBub3QgdG8gZG8gYSBj
b29raWUgZXhjaGFuZ2Ugd2hlbiBhIHNlc3Npb24gaXMNCiAgIHJlc3VtZWQuICBTdGlsbCwgY2xp
ZW50cyBoYXZlIHRvIGJlIHByZXBhcmVkIHRvIGRvIGEgY29va2llIGV4Y2hhbmdlDQogICB3aXRo
IGV2ZXJ5IGhhbmRzaGFrZS4gIFRoZSBjb29raWUgZXhjaGFuZ2UgaXMgbm90IHNob3duIGluIHRo
ZQ0KICAgZmlndXJlLg0KDQoNCiAgICAgICAgIENsaWVudCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVyDQogICAgICAgICAtLS0tLS0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLQ0KDQogICAgICAgICBD
bGllbnRIZWxsbyAgICAgICAgICAgICAgICAgICAtLS0tLS0tLT4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZXJ2ZXJIZWxsbw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW0NoYW5nZUNp
cGhlclNwZWNdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0t
LS0gICAgICAgICAgICAgRmluaXNoZWQNCiAgICAgICAgIFtDaGFuZ2VDaXBoZXJTcGVjXQ0KICAg
ICAgICAgRmluaXNoZWQgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0+DQogICAgICAgICBB
cHBsaWNhdGlvbiBEYXRhICAgICAgICAgICAgICA8LS0tLS0tLT4gICAgIEFwcGxpY2F0aW9uIERh
dGENCg0KDQogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA4OiBEVExTIFNlc3Npb24gUmVzdW1w
dGlvbi4NCg0KICAgQ29uc3RyYWluZWQgY2xpZW50cyBNVVNUIGltcGxlbWVudCBzZXNzaW9uIHJl
c3VtcHRpb24gdG8gaW1wcm92ZSB0aGUNCiAgIHBlcmZvcm1hbmNlIG9mIHRoZSBoYW5kc2hha2Uu
ICBUaGlzIHdpbGwgbGVhZCB0byBhIHJlZHVjZWQgbnVtYmVyIG9mDQogICBtZXNzYWdlIGV4Y2hh
bmdlcywgbG93ZXIgY29tcHV0YXRpb25hbCBvdmVyaGVhZCAoc2luY2Ugb25seSBzeW1tZXRyaWMN
CiAgIGNyeXB0b2dyYXBoeSBpcyB1c2VkIGR1cmluZyBhIHNlc3Npb24gcmVzdW1wdGlvbiBleGNo
YW5nZSksIGFuZA0KICAgc2Vzc2lvbiByZXN1bXB0aW9uIHJlcXVpcmVzIGxlc3MgYmFuZHdpZHRo
Lg0KDQogICBGb3IgY2FzZXMgd2hlcmUgdGhlIHNlcnZlciBpcyBjb25zdHJhaW5lZCAoYnV0IG5v
dCB0aGUgY2xpZW50KSB0aGUNCiAgIGNsaWVudCBNVVNUIGltcGxlbWVudCBSRkMgNTA3NyBbUkZD
NTA3N10uICBSRkMgNTA3NyBzcGVjaWZpZXMgYQ0KICAgdmVyc2lvbiBvZiBUTFMvRFRMUyBzZXNz
aW9uIHJlc3VtcHRpb24gdGhhdCBkb2VzIG5vdCByZXF1aXJlIHBlci0NCiAgIHNlc3Npb24gc3Rh
dGUgaW5mb3JtYXRpb24gdG8gYmUgbWFpbnRhaW5lZCBieSB0aGUgY29uc3RyYWluZWQgc2VydmVy
Lg0KICAgVGhpcyBpcyBhY2NvbXBsaXNoZWQgYnkgdXNpbmcgYSB0aWNrZXQtYmFzZWQgYXBwcm9h
Y2guDQoNCiAgIElmIGJvdGggdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBhcmUgY29uc3RyYWlu
ZWQgZGV2aWNlcyBib3RoDQogICBkZXZpY2VzIFNIT1VMRCBpbXBsZW1lbnQgUkZDIDUwNzcgYW5k
IE1VU1QgaW1wbGVtZW50IGJhc2ljIHNlc3Npb24NCiAgIHJlc3VtcHRpb24uDQoNCg0KMTQuICBS
YW5kb20gTnVtYmVyIEdlbmVyYXRpb24NCg0KICAgVGhlIFRMUy9EVExTIHByb3RvY29sIHJlcXVp
cmVzIHJhbmRvbSBudW1iZXJzIHRvIGJlIGF2YWlsYWJsZSBkdXJpbmcNCiAgIHRoZSBwcm90b2Nv
bCBydW4uICBGb3IgZXhhbXBsZSwgZHVyaW5nIHRoZSBDbGllbnRIZWxsbyBhbmQgdGhlDQogICBT
ZXJ2ZXJIZWxsbyBleGNoYW5nZSB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyIGV4Y2hhbmdlIHJh
bmRvbQ0KICAgbnVtYmVycy4gIEFsc28sIHRoZSB1c2Ugb2YgdGhlIERpZmZpZS1IZWxsbWFuIGV4
Y2hhbmdlIHJlcXVpcmVzDQogICByYW5kb20gbnVtYmVycyBkdXJpbmcgdGhlIGtleSBwYWlyIGdl
bmVyYXRpb24uICBTcGVjaWFsIGNhcmUgaGFzIHRvDQogICBiZSBwYWlkIHdoZW4gZ2VuZXJhdGlu
ZyByYW5kb20gbnVtYmVycyBpbiBlbWJlZGRlZCBzeXN0ZW1zIGFzIG1hbnkNCiAgIGVudHJvcHkg
c291cmNlcyBhdmFpbGFibGUgb24gZGVza3RvcCBvcGVyYXRpbmcgc3lzdGVtcyBvciBtb2JpbGUN
CiAgIGRldmljZXMgbWlnaHQgYmUgbWlzc2luZywgYXMgZGVzY3JpYmVkIGluIFtIZW5pbmdlcl0u
ICBDb25zZXF1ZW50bHksDQogICBpZiBub3QgZW5vdWdoIHRpbWUgaXMgZ2l2ZW4gZHVyaW5nIHN5
c3RlbSBzdGFydCB0aW1lIHRvIGZpbGwgdGhlDQogICBlbnRyb3B5IHBvb2wgdGhlbiB0aGUgb3V0
cHV0IG1pZ2h0IGJlIHByZWRpY3RhYmxlIGFuZCByZXBlYXRhYmxlLCBmb3INCiAgIGV4YW1wbGUg
bGVhZGluZyB0byB0aGUgc2FtZSBrZXlzIGdlbmVyYXRlZCBhZ2FpbiBhbmQgYWdhaW4uDQoNCiAg
IEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgc291cmNlcyBjb250cmlidXRpbmcgdG8gdGhl
IHJhbmRvbW5lc3MNCiAgIHBvb2wgb24gbGFwdG9wcywgb3IgZGVza3RvcCBQQ3MgYXJlIG5vdCBh
dmFpbGFibGUgb24gbWFueSBJb1QgZGV2aWNlLA0KICAgc3VjaCBhcyBtb3VzZSBtb3ZlbWVudCwg
dGltaW5nIG9mIGtleXN0cm9rZXMsIGFpciB0dXJidWxlbmNlIG9uIHRoZQ0KICAgbW92ZW1lbnQg
b2YgaGFyZCBkcml2ZSBoZWFkcywgZXRjLiAgT3RoZXIgc291cmNlcyBoYXZlIHRvIGJlIGZvdW5k
IG9yDQogICBkZWRpY2F0ZWQgaGFyZHdhcmUgaGFzIHRvIGJlIGFkZGVkLg0KDQogICBUaGUgQ2xp
ZW50SGVsbG8gYW5kIHRoZSBTZXJ2ZXJIZWxsbyBtZXNzYWdlcyBjb250YWlucyB0aGUgJ1JhbmRv
bScNCiAgIHN0cnVjdHVyZSwgd2hpY2ggaGFzIHR3byBjb21wb25lbnRzOiBnbXRfdW5peF90aW1l
IGFuZCBhIHJhbmRvbQ0KICAgc2VxdWVuY2Ugb2YgMjggcmFuZG9tIGJ5dGVzLiBnbXRfdW5peF90
aW1lIGhvbGRzIHRoZSBjdXJyZW50IHRpbWUgYW5kDQogICBkYXRlIGluIHN0YW5kYXJkIFVOSVgg
MzItYml0IGZvcm1hdCAoc2Vjb25kcyBzaW5jZSB0aGUgbWlkbmlnaHQNCiAgIHN0YXJ0aW5nIEph
biAxLCAxOTcwLCBHTVQpLiAgW0ktRC5tYXRoZXdzb24tbm8tZ210dW5peHRpbWVdIGFyZ3Vlcw0K
ICAgdGhhdCB0aGUgZW50aXJlIENsaWVudEhlbGxvLlJhbmRvbSB2YWx1ZSAoaW5jbHVkaW5nIGdt
dF91bml4X3RpbWUpDQogICBzaG91bGQgYmUgc2V0IHRvIGEgY3J5cHRvZ3JhcGhpY2FsbHkgcmFu
ZG9tIHNlcXVlbmNlIGJlY2F1c2Ugb2YNCiAgIHByaXZhY3kgY29uY2VybnMgcmVnYXJkaW5nIGRl
dmljZSBmaW5nZXJwcmludGluZy4gIFNpbmNlIG1hbnkgSW9UDQogICBkZXZpY2VzIGRvIG5vdCBo
YXZlIGFjY2VzcyB0byBhIHJlYWwtdGltZSBjbG9jayB0aGlzIHJlY29tbWVuZGF0aW9uDQogICBp
dCBpcyBSRUNPTU1FTkRFRCB0byBmb2xsb3cgdGhlIGd1aWRhbmNlIG91dGxpbmVkIGluDQogICBb
SS1ELm1hdGhld3Nvbi1uby1nbXR1bml4dGltZV0gcmVnYXJkaW5nIHRoZSBjb250ZW50IG9mIHRo
ZQ0KICAgQ2xpZW50SGVsbG8uUmFuZG9tIGZpZWxkLiAgSG93ZXZlciwgZm9yIHRoZSBTZXJ2ZXJI
ZWxsby5SYW5kb20NCiAgIHN0cnVjdHVyZSBpdCBpcyBSRUNPTU1FTkRFRCB0byBtYWludGFpbiB0
aGUgZXhpc3Rpbmcgc3RydWN0dXJlIHdpdGgNCiAgIGdtdF91bml4X3RpbWUgZm9sbG93ZWQgYnkg
YSByYW5kb20gc2VxdWVuY2Ugb2YgMjggcmFuZG9tIGJ5dGVzIHNpbmNlDQogICB0aGUgY2xpZW50
IGNhbiB1c2UgdGhlIHJlY2VpdmVkIHRpbWUgaW5mb3JtYXRpb24gdG8gc2VjdXJlbHkgb2J0YWlu
DQogICB0aW1lIGluZm9ybWF0aW9uLiAgRm9yIGNvbnN0cmFpbmVkIHNlcnZlcnMgaXQgY2Fubm90
IGJlIGFzc3VtZWQgdGhhdA0KICAgdGhleSBtYWludGFpbiBhY2N1cmF0ZSB0aW1lIGluZm9ybWF0
aW9uOyB0aGVzZSBkZXZpY2VzIE1VU1QgaW5jbHVkZQ0KICAgdGltZSBpbmZvcm1hdGlvbiBpbiB0
aGUgU2VydmVyLlJhbmRvbSBzdHJ1Y3R1cmUgd2hlbiB0aGV5IGFjdHVhbGx5DQogICBvYnRhaW4g
YWNjdXJhdGUgdGltZSBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSB1dGlsaXplZCBieSBjbGllbnRz
Lg0KICAgQ2xpZW50cyBNVVNUIG9ubHkgdXNlIHRpbWUgaW5mb3JtYXRpb24gb2J0YWluZWQgZnJv
bSBzZXJ2ZXJzIHRoZXkNCiAgIHRydXN0Lg0KDQogICBJb1QgZGV2aWNlcyB1c2luZyBUTFMvRFRM
UyBNVVNUIG9mZmVyIHdheXMgdG8gZ2VuZXJhdGUgcXVhbGl0eSByYW5kb20NCiAgIG51bWJlcnMu
ICBHdWlkZWxpbmVzIGFuZCByZXF1aXJlbWVudHMgZm9yIHJhbmRvbSBudW1iZXIgZ2VuZXJhdGlv
bg0KICAgY2FuIGJlIGZvdW5kIGluIFJGQyA0MDg2IFtSRkM0MDg2XS4NCg0KDQoxNi4gIFNlcnZl
ciBOYW1lIEluZGljYXRpb24gKFNOSSkNCg0KICAgVGhlIFNlcnZlciBOYW1lIEluZGljYXRpb24g
ZXh0ZW5zaW9uIGRlZmluZWQgaW4gW1JGQzYwNjZdIGRlZmluZXMgYQ0KICAgbWVjaGFuaXNtIGZv
ciBhIGNsaWVudCB0byB0ZWxsIGEgVExTL0RUTFMgc2VydmVyIHRoZSBuYW1lIG9mIHRoZQ0KICAg
c2VydmVyIGl0IHdhbnRzIHRvIGNvbnRhY3QuICBUaGlzIGlzIGEgdXNlZnVsIGV4dGVuc2lvbiBm
b3IgbWFueQ0KICAgaG9zdGluZyBlbnZpcm9ubWVudHMgd2hlcmUgbXVsdGlwbGUgdmlydHVhbCBz
ZXJ2ZXJzIGFyZSBydW4gb24gc2luZ2xlDQogICBJUCBhZGRyZXNzLg0KDQogICBUaGlzIHNwZWNp
ZmljYXRpb24gUkVDT01NRU5EcyB0aGUgaW1wbGVtZW50YXRpb24gb2YgUkZDIDYwNjYgdW5sZXNz
DQogICBpdCBpcyBrbm93biB0aGF0IGEgVExTL0RUTFMgY2xpZW50IGRvZXMgbm90IGludGVyYWN0
IHdpdGggYSBzZXJ2ZXIgaW4NCiAgIGEgaG9zdGluZyBlbnZpcm9ubWVudC4NCg0KDQoNCg==


From nobody Thu Dec 18 07:03:53 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE09C1A8A79 for ; Thu, 18 Dec 2014 07:03:50 -0800 (PST)
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 0CJyXrD1Jvmc for ; Thu, 18 Dec 2014 07:03:45 -0800 (PST)
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 F3F991A8A7F for ; Thu, 18 Dec 2014 07:03:17 -0800 (PST)
Received: from [192.168.131.138] ([80.92.123.25]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MVdfD-1YQY8a3uBD-00Yvl5 for ; Thu, 18 Dec 2014 16:03:16 +0100
Message-ID: <5492ECB3.90502@gmx.net>
Date: Thu, 18 Dec 2014 16:03:15 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" 
References: <9E083D30-A338-4668-8B9A-1A6564E3623C@muada.com>
In-Reply-To: <9E083D30-A338-4668-8B9A-1A6564E3623C@muada.com>
OpenPGP: id=4D776BC9
X-Forwarded-Message-Id: <9E083D30-A338-4668-8B9A-1A6564E3623C@muada.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wHCpCTtGWJsjU5WBGj8Te7on1Oo7TnA2U"
X-Provags-ID: V03:K0:g+tI+CVl5lVX9tHfb6gPlwFl8zKohefeBFRyV13TkbF/BgK2CY2 4WhtJOM+JrhbSdZCEiSrTaEGXvPensjLrSxsoXQDl8oh7FOeZtsaiU2Tbq83KuBwtJ/N+JO svZAxnZr539HOkG0nkkFV+lwKl9TmvS/xi5K7b6ig18X4nr7oYJK+Qh3qc44ixDcn1IbAsH so+tV4WCahqKgq731oBbA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/WS4wwd_3dlnM3-zk3ksgfPbKm6Q
Subject: [Dtls-iot] Fwd: [Int-area] Quick MTU measurements
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, 18 Dec 2014 15:03:50 -0000

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

Just got this mail; very timely.

-------- Forwarded Message --------
Subject: [Int-area] Quick MTU measurements
Date: Thu, 18 Dec 2014 15:58:13 +0100
From: Iljitsch van Beijnum 
To: int-area@ietf.org

Hi all,

We had some discussions on MTU issues on the v6ops list, which prompted
me to do some quick measurements, please see:

Maximum packet sizes on the internet
http://www.bgpexpert.com/article.php?article=3D151

Internet packet sizes part 2: IPv4 path MTU discovery is dead
http://www.bgpexpert.com/article.php?article=3D152

Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they can
handle at least 1280 bytes in their TCP MSS and about 65% can handle 1500=
=2E

In almost a week, I didn't get a single IPv4 too big, so it seems that
in practice, IPv4 PMTUD is no longer used. (Please confirm with a larger
dataset before taking any actions based on this!) However, depending on
PMTUD doesn't lead to obvious problems with IPv6.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area




--wHCpCTtGWJsjU5WBGj8Te7on1Oo7TnA2U
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

iQEcBAEBCgAGBQJUkuyzAAoJEGhJURNOOiAtqFYH/19Py9ycxtNgt9lPRM4oS30X
vu/GxIzGVpjM+JEPt8ukWc9wilFBj2XEACUVKRq6qj4S2a2c0GcANf/3JJ+DX56u
dVHFvt8dX07NwUeokNBuZG38/Ap3YTz9xuyM8zhtblzKkQQxK0hbFByJQ207OC6j
ltpTUpGzTdNBda8CbMwzfLKP/4jPKMin2oHbkJ37/7we4ThhhOGp8402uBNIqKN2
NqOTrMXPrcdyfPBaJFg73Fx8chxkJS0dTQZS1WbeJR0Q8D+PZBiWNmuNESuz2ib5
SyCkG9LxHOkdjgSrPnwDeipoBIdtWtQXzWW05de7FeitpTNQ3p9/4sO6QN1a+JA=
=GBQG
-----END PGP SIGNATURE-----

--wHCpCTtGWJsjU5WBGj8Te7on1Oo7TnA2U--


From nobody Thu Dec 18 08:09:10 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC371A8AA9 for ; Thu, 18 Dec 2014 08:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpiosWZExF4L for ; Thu, 18 Dec 2014 08:08:56 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A82A1A1B2C for ; Thu, 18 Dec 2014 08:08:51 -0800 (PST)
Received: by mail-ig0-f173.google.com with SMTP id r2so1133348igi.6 for ; Thu, 18 Dec 2014 08:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=0ezwnSoN3M+efMqIXfYDE9JyQs/4/nG6j/HuNjhdTu0=; b=ci8udpIaA2TrezMX2mxH4rkxZO971vdNDMwAQRpfbjDHP2kMwRn+UH4lvw5B0eXVH3 12+NAyYRK0Xx2rFTDVWBpXa8qUT39wW8sRpEH850ybfPH1sBqmvYYUPlb5LfW7/Si8BM atJeEpLOhZLd9To+GeBdL0kqLT/xdEpG03+V0aYkXFibp9SAPBVHNDYuR6c/6TXDKSm3 rDfu+xe0mxl/Vd/A/EP8MwVbPJ25WZBY/XT8qrCkWUW7Tac0IF4mv0tS5JsWMj9Qk1Ro Tk+R+ZoRt0BF/RkYnAJStgI6y2DdrDHWMSmcVdhUcM5Ix9rFIImIE7vFNaORfvYbp5CV D1Sg==
X-Received: by 10.50.43.136 with SMTP id w8mr3071398igl.33.1418918929884; Thu, 18 Dec 2014 08:08:49 -0800 (PST)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id a126sm3329972ioa.13.2014.12.18.08.08.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Dec 2014 08:08:49 -0800 (PST)
Message-ID: <5492FC10.3000204@gmail.com>
Date: Thu, 18 Dec 2014 11:08:48 -0500
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Hannes Tschofenig ,  "dtls-iot@ietf.org" 
References: <9E083D30-A338-4668-8B9A-1A6564E3623C@muada.com> <5492ECB3.90502@gmx.net>
In-Reply-To: <5492ECB3.90502@gmx.net>
Content-Type: multipart/alternative; boundary="------------000707040306070707040406"
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/F6w3j3hcnkdfobV9kg0OUAXpTrM
Subject: Re: [Dtls-iot] Fwd: [Int-area] Quick MTU measurements
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, 18 Dec 2014 16:09:03 -0000

This is a multi-part message in MIME format.
--------------000707040306070707040406
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit


Hi Hannes:

I was intrigued by the following snippet in your second pointer:

    "With IPv6, if you want to send packets larger than 1280 bytes,
    PMTUD is mandatory, as routers aren't allowed to fragment IPv6 packets."

Does this have implications if the MAC layer only supports small frame 
sizes (such as 127 bytes with classic 802.15.4)?

Best regards, Rene


On 12/18/2014 10:03 AM, Hannes Tschofenig wrote:
> Just got this mail; very timely.
>
> -------- Forwarded Message --------
> Subject: [Int-area] Quick MTU measurements
> Date: Thu, 18 Dec 2014 15:58:13 +0100
> From: Iljitsch van Beijnum 
> To: int-area@ietf.org
>
> Hi all,
>
> We had some discussions on MTU issues on the v6ops list, which prompted
> me to do some quick measurements, please see:
>
> Maximum packet sizes on the internet
> http://www.bgpexpert.com/article.php?article=151
>
> Internet packet sizes part 2: IPv4 path MTU discovery is dead
> http://www.bgpexpert.com/article.php?article=152
>
> Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they can
> handle at least 1280 bytes in their TCP MSS and about 65% can handle 1500.
>
> In almost a week, I didn't get a single IPv4 too big, so it seems that
> in practice, IPv4 PMTUD is no longer used. (Please confirm with a larger
> dataset before taking any actions based on this!) However, depending on
> PMTUD doesn't lead to obvious problems with IPv6.
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
>
>
>
>
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot


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


--------------000707040306070707040406
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
        Hi Hannes:
    
        
    
        I was intrigued by the following snippet in your second pointer:
    
          
      
    "With IPv6, if you want
          to send packets larger than 1280 bytes, PMTUD is mandatory, as
          routers aren't allowed to fragment IPv6 packets." 
    
        
    
      
    
      Does this have implications if the MAC layer only supports small
      frame sizes (such as 127 bytes with classic 802.15.4)? 
    
      
    
      Best regards, Rene
    
      
    
      
    
            On 12/18/2014 10:03 AM, Hannes Tschofenig wrote:
    
    
    
    
    
      
    Just got this mail; very timely.

-------- Forwarded Message --------
Subject: [Int-area] Quick MTU measurements
Date: Thu, 18 Dec 2014 15:58:13 +0100
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: int-area@ietf.org

Hi all,

We had some discussions on MTU issues on the v6ops list, which prompted
me to do some quick measurements, please see:

Maximum packet sizes on the internet
http://www.bgpexpert.com/article.php?article=151

Internet packet sizes part 2: IPv4 path MTU discovery is dead
http://www.bgpexpert.com/article.php?article=152

Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they can
handle at least 1280 bytes in their TCP MSS and about 65% can handle 1500.

In almost a week, I didn't get a single IPv4 too big, so it seems that
in practice, IPv4 PMTUD is no longer used. (Please confirm with a larger
dataset before taking any actions based on this!) However, depending on
PMTUD doesn't lead to obvious problems with IPv6.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area




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

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


--------------000707040306070707040406--


From nobody Sun Dec 21 23:58:48 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADCA1A888A; Sun, 21 Dec 2014 23:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNm5qol-SLLb; Sun, 21 Dec 2014 23:58:44 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F971A0172; Sun, 21 Dec 2014 23:58:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141222075844.5412.50213.idtracker@ietfa.amsl.com>
Date: Sun, 21 Dec 2014 23:58:44 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/9N3Bz-8WCQDt2LY7-fIWL4h64ms
Cc: dtls-iot@ietf.org
Subject: [Dtls-iot] I-D Action: draft-ietf-dice-profile-08.txt
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DTLS for IoT discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 07:58:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DTLS In Constrained Environments Working Group of the IETF.

        Title           : A TLS/DTLS 1.2 Profile for the Internet of Things
        Authors         : Hannes Tschofenig
                          Thomas Fossati
	Filename        : draft-ietf-dice-profile-08.txt
	Pages           : 45
	Date            : 2014-12-21

Abstract:
   A common design pattern in Internet of Things (IoT) deployments is
   the use of a constrained device (typically providing sensor data)
   that makes data available for home automation, industrial control
   systems, smart cities and other IoT deployments.

   This document defines a Transport Layer Security (TLS) and Datagram
   TLS 1.2 profile that offers communications security for this data
   exchange thereby preventing eavesdropping, tampering, and message
   forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dice-profile/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dice-profile-08

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Dec 22 00:06:55 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD31A0178 for ; Mon, 22 Dec 2014 00:06:51 -0800 (PST)
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 76T5gdT5E3Qo for ; Mon, 22 Dec 2014 00:06:50 -0800 (PST)
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 495D11A8A06 for ; Mon, 22 Dec 2014 00:06:40 -0800 (PST)
Received: from [192.168.131.138] ([80.92.123.20]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LezI3-1XYL221Vx1-00qg5N for ; Mon, 22 Dec 2014 09:06:38 +0100
Message-ID: <5497D109.70507@gmx.net>
Date: Mon, 22 Dec 2014 09:06:33 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.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="k5A60Uxbgs7O7G5cI13Xds3rTTgqeTpEj"
X-Provags-ID: V03:K0:ySalPDYT4tt9X++mAsbttXJ+nU5T3imh5DNZjusu5Q11dZBYp2Y txQ4H2ZR/whC7SJ2io2uULeAVugIIPagF9Ce7HOMyouRxqXVgtP8B08ZkYvZ+GDE8c/qs1C wPqRvzZEv1LOBqFzdvRUhUuKJwMkSjesloIK7JUuJ5hrfjbrCUSs5z6bI2HM6DlYcKKx89i kNufuoF71+9U/ACkR/bEg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/QVZXwsrKrcpTEqosI_rtvYDhHNU
Subject: [Dtls-iot] draft-ietf-dice-profile-08.txt
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, 22 Dec 2014 08:06:53 -0000

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

I just submitted version -08 of the profile document:
http://tools.ietf.org/html/draft-ietf-dice-profile-08

It contains the proposed text for the DTLS fragmentation (which is still
marked as proposed since we haven't gotten a lot of feedback yet and I
am also not sure whether the recommendation is indeed helpful).

It also contains the text about the constrained server but that requires
more review as well (and an some figures).

Hence, there will be a version -09 in January.

Ciao
Hannes


--k5A60Uxbgs7O7G5cI13Xds3rTTgqeTpEj
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

iQEcBAEBCgAGBQJUl9EJAAoJEGhJURNOOiAthhQH/2KPS6af88rPbkGSvvM0ZtoE
gmQ7SCp4DV3rE8BvdbYGOHtndeg7RIYnELdOt1csr9GJxJkjgVMteYC/+uSvuivq
R5TpbjbakUTlS5la2RcEQ0AXg6CZqIMX0YIR1ELVhpxLKe9AiSeXvFuO8WwQN8Ck
wWQ9LWKsd/qs+CYWvV5XuH84bDn/DZLEVrYXvYUqxU5NFX/a/yCnW9M4NR+fX5cb
tfp41ORQ34NpmeJnf4G3zpkJiIwWT4at69d/T+cM49SQ0u68oGJB2agqU0kamEHS
ly5+Bmg67Pq9WHZc66Vfo9K/stOssGaQaQRQyCxm3gvqsVITi6zAdQUX/CgBjjg=
=azBH
-----END PGP SIGNATURE-----

--k5A60Uxbgs7O7G5cI13Xds3rTTgqeTpEj--


From nobody Mon Dec 22 00:08:13 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D551A888A for ; Mon, 22 Dec 2014 00:08:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 xQ2oVftoXEM7 for ; Mon, 22 Dec 2014 00:08:08 -0800 (PST)
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 5B5201A0178 for ; Mon, 22 Dec 2014 00:08:08 -0800 (PST)
Received: from [192.168.131.138] ([80.92.123.20]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDW9x-1Y8Dl83ZJl-00GqN2; Mon, 22 Dec 2014 09:08:06 +0100
Message-ID: <5497D15E.2090101@gmx.net>
Date: Mon, 22 Dec 2014 09:07:58 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Rahman, Akbar" ,  "dtls-iot@ietf.org" 
References: <5492BF33.6040209@gmx.net> <36F5869FE31AB24485E5E3222C288E1F08F4BC@NABESITE.InterDigital.com>
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F08F4BC@NABESITE.InterDigital.com>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sJcUMp94fewLLd6csw5dcm7AGvvTBa4Iu"
X-Provags-ID: V03:K0:yX9neX7GbeXki0ZZxIO7ZuDY2HAaDk9Hq6UO/HNwsdbepoarCZx OVWF2tlFRueVE0CIxN4wfs5bYTz1GRuc6jrBrNfnvTCzZRc16o30WqaEQJaPNRl3wArOtMG dmwjaj3D5nn/PiMUu9xe4ZNu6TDfLto+BW9tonwXiWm6y/rWfImD2WhNrmmqAAg8/hCCn3Y n2r+DQIcR7+gGfHLkGDKA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Di4Ib6zoLUzBWEspdyDObduAkj0
Subject: Re: [Dtls-iot] Constrained Servers (ticket#16)
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, 22 Dec 2014 08:08:11 -0000

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

Thanks for the quick response, Akbar.

I am going to add a figure with version -09.

Ciao
Hannes

On 12/18/2014 03:49 PM, Rahman, Akbar wrote:
> Hi Hannes,
>=20
>=20
> I took a quick scan of it and it looks very good.  The only minor sugge=
stion that I have is if you could include a simple figure in section 4.2 =
(similar to your Figure 1 in section 4.1).  But this is only a Nice To Ha=
ve suggestion and not a Must Have.
>=20
>=20
> Best Regards,
>=20
>=20
> Akbar
>=20
> -----Original Message-----
> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Hannes T=
schofenig
> Sent: Thursday, December 18, 2014 6:49 AM
> To: dtls-iot@ietf.org
> Subject: [Dtls-iot] Constrained Servers (ticket#16)
>=20
> Hi all,
>=20
> I have been trying to resolve the comments related to the constrained s=
erver discussion and the changes are as follows (see latest document vers=
ion at
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-pro=
file/draft-ietf-dice-profile-08.txt):
>=20
> - Expanded the text for the constrained client and moved text around (s=
ee Section 4.1).
>=20
> - Added new text for the constrained server case to Section 4.2 (see al=
so below) based on the recent email exchange (link:
> http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00529.html).
>=20
> - Updated Section 9 "Session Resumption", Section 14 "Random Number Gen=
eration", and Section 16 "Server Name Indication). I copied the relevant =
section into this email.
>=20
> Ciao
> Hannes
>=20
>=20
> ----------
>=20
> 4.2.  Constrained TLS/DTLS Servers
>=20
>    Section 4.1 illustrates deployment models where the TLS/DTLS client
>    is constrained and efforts need to be taken to improve memory
>    utilization, bandwidth consumption, reduce performance impacts, etc.=

>    In this section we look at cases where constrained devices run TLS/
>    DTLS servers to secure access to an application layer protocol
>    server, like a CoAP or HTTP server.  Running server functionality on=

>    a constrained node is typically more demanding since servers have to=

>    listen and wait for incoming requests.  Therefore, they will have
>    fewer possibilities to enter sleeping cycles.  Nevertheless, there
>    are legitimate reasons to deploy servers as constrained devices.
>=20
>    A deployment with constrained servers has to overcome several
>    challenges.  Later we will explain how these challenges has been
>    solved using CoAP as an example.  Other protocols may offer similar
>    capabilities.  While the requirements for the TLS/DTLS protocol
>    profile change only slightly when run on a constrained server (in
>    comparison to running it on a constrained client) several other eco-=

>    system factor will impact deployment.
>=20
>    The challenges are:
>=20
>    Discovery and Reachability:
>=20
>       Before initiating a connection to a constrained server a client
>       first needs to discover that server and, once discovered, it need=
s
>       to maintain reachability with that device.
>=20
>       In CoAP the discovery of resources offered by servers is
>       accomplished by sending a unicast or multicast CoAP GET to a well=
-
>       known URI.  The CORE Link format specification [RFC6690] describe=
s
>       the use case (see Section 1.2.1), and reserves the URI (see
>       Section 7.1).  Section 7 of the CoAP specification [RFC7252]
>       describes the discovery procedure.  RFC 7390 [RFC7390] describes
>       use case for discovering CoAP servers using multicast (see
>       Section 3.3), and specifies the protocol processing rules for CoA=
P
>       group communications (see Section 2.7).
>=20
>    Authentication:
>=20
>       The next challenge concerns the provisioning of authentication
>       credentials to the clients as well as servers.  In Section 4.1 we=

>       assumed that credentials (and other configuration information) ar=
e
>       provisioned to the device and that those can be used with the
>       authorization servers.  Of course, this leads to a very static
>       relationship between the clients and their server-side
>       infrastructure but poses fewer challenges from a deployment point=

>       of view, as described in Section 2 of
>       [I-D.iab-smart-object-architecture] these different communication=

>       patterns.  In any case, engineers and product designers have to
>       determine how the relevant credentials are distributed to the
>       respective parties.  For example, shared secrets may need to be
>       provisioned to clients and the constrained servers for subsequent=

>       use of TLS/DTLS PSK.  In other deployments, certificates, private=

>       keys, and trust anchors for use with certificate-based
>       authentication may need to be utilized.
>=20
>       Practical solutions either use pairing (also called imprinting) o=
r
>       a trusted third party.  With pairing two devices execute a specia=
l
>       protocol exchange that is unauthenticated to establish an shared
>       key (for example using an unauthenticated Diffie-Hellman exchange=
)
>       key.  To avoid man-in-the-middle attacks an out-of-band channel i=
s
>       used to verify that nobody has tampered with the exchanged
>       protocol messages.  This out-of-band channel can come in many
>       forms, including:
>=20
>       *  Human involvement by comparing hashed keys, entering passkeys,=

>          scanning QR codes
>=20
>       *  The use of alternative wireless communication channels (e.g.,
>          infra-red communication in addition to WiFi)
>=20
>       *  Proximity-based information
>=20
>       More details about these different pairing/imprinting techniques
>       can be found in the smart object security workshop report
>       [RFC7397] and various position papers submitted to that topic,
>       such as [ImprintingSurvey].  The use of a trusted third party
>       follows a different approach and is subject to ongoing
>       standardization efforts in the 'Authentication and Authorization
>       for Constrained Environments (ACE)' working group.
>=20
>    Authorization
>=20
>       The last challenge is the ability for the constrained server to
>       make an authorization decision when clients access protected
>       resources.  Pre-provisioning access control information to
>       constrained servers may be one option but works only in a small
>       scale, less dynamic environment.  For a more fine-grained and
>       dynamic access control the reader is referred to the ongoing work=

>       in the ACE working group.
>=20
>=20
> 9.  Session Resumption
>=20
>    Session resumption is a feature of the core TLS/DTLS specifications
>    that allows a client to continue with an earlier established session=

>    state.  The resulting exchange is shown in Figure 8.  In addition,
>    the server may choose not to do a cookie exchange when a session is
>    resumed.  Still, clients have to be prepared to do a cookie exchange=

>    with every handshake.  The cookie exchange is not shown in the
>    figure.
>=20
>=20
>          Client                                               Server
>          ------                                               ------
>=20
>          ClientHello                   -------->
>                                                           ServerHello
>                                                    [ChangeCipherSpec]
>                                        <--------             Finished
>          [ChangeCipherSpec]
>          Finished                      -------->
>          Application Data              <------->     Application Data
>=20
>=20
>                     Figure 8: DTLS Session Resumption.
>=20
>    Constrained clients MUST implement session resumption to improve the=

>    performance of the handshake.  This will lead to a reduced number of=

>    message exchanges, lower computational overhead (since only symmetri=
c
>    cryptography is used during a session resumption exchange), and
>    session resumption requires less bandwidth.
>=20
>    For cases where the server is constrained (but not the client) the
>    client MUST implement RFC 5077 [RFC5077].  RFC 5077 specifies a
>    version of TLS/DTLS session resumption that does not require per-
>    session state information to be maintained by the constrained server=
=2E
>    This is accomplished by using a ticket-based approach.
>=20
>    If both the client and the server are constrained devices both
>    devices SHOULD implement RFC 5077 and MUST implement basic session
>    resumption.
>=20
>=20
> 14.  Random Number Generation
>=20
>    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.  Special care has to
>    be paid 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.
>=20
>    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 o=
r
>    dedicated hardware has to be added.
>=20
>    The ClientHello and the ServerHello messages contains the 'Random'
>    structure, which has two components: gmt_unix_time and a random
>    sequence of 28 random bytes. gmt_unix_time holds the current time an=
d
>    date in standard UNIX 32-bit format (seconds since the midnight
>    starting Jan 1, 1970, GMT).  [I-D.mathewson-no-gmtunixtime] argues
>    that the entire ClientHello.Random value (including gmt_unix_time)
>    should be set to a cryptographically random sequence because of
>    privacy concerns regarding device fingerprinting.  Since many IoT
>    devices do not have access to a real-time clock this recommendation
>    it is RECOMMENDED to follow the guidance outlined in
>    [I-D.mathewson-no-gmtunixtime] regarding the content of the
>    ClientHello.Random field.  However, for the ServerHello.Random
>    structure it is RECOMMENDED to maintain the existing structure with
>    gmt_unix_time followed by a random sequence of 28 random bytes since=

>    the client can use the received time information to securely obtain
>    time information.  For constrained servers it cannot be assumed that=

>    they maintain accurate time information; these devices MUST include
>    time information in the Server.Random structure when they actually
>    obtain accurate time information that can be utilized by clients.
>    Clients MUST only use time information obtained from servers they
>    trust.
>=20
>    IoT devices using TLS/DTLS MUST offer ways to generate quality rando=
m
>    numbers.  Guidelines and requirements for random number generation
>    can be found in RFC 4086 [RFC4086].
>=20
>=20
> 16.  Server Name Indication (SNI)
>=20
>    The Server Name Indication extension defined in [RFC6066] defines a
>    mechanism for a client to tell a TLS/DTLS server the name of the
>    server it wants to contact.  This is a useful extension for many
>    hosting environments where multiple virtual servers are run on singl=
e
>    IP address.
>=20
>    This specification RECOMMENDs the implementation of RFC 6066 unless
>    it is known that a TLS/DTLS client does not interact with a server i=
n
>    a hosting environment.
>=20
>=20
>=20
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot
>=20


--sJcUMp94fewLLd6csw5dcm7AGvvTBa4Iu
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

iQEcBAEBCgAGBQJUl9FeAAoJEGhJURNOOiAtU9cH/AhhHBlUZNXQsVKWphhJ/Tva
6JNf+/+k6yRrnDxyp+wZnv+c2u7coBpBRt6mCHgvJG+yMD55C20Qac1Abn7JYpJM
DmOqqdPVDpCAXJYfxKPyJuB3IwPaa019fzz8HNs1RAItWFSsaUy4Wa4p5P1+FjN5
3QNhxmNirm9ujqcPk8gBTfx6DbRY1vpOAObjjasAy3MlK50JJCr6PFDht3M44U9r
5vmJouCMhV0QdWzUiDCCgTee1wEWWSwscibHs03cI55DACWy8ocVfkTW9AQ1bGfb
7HZdmfvIsKK2Ku8V9yN3a49Unk/2wU82MRZk31UTF+BmxaOxAUUTChgMV1lP6ZI=
=uvRo
-----END PGP SIGNATURE-----

--sJcUMp94fewLLd6csw5dcm7AGvvTBa4Iu--


From nobody Mon Dec 22 00:33:22 2014
Return-Path: 
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C782C1A02BE for ; Mon, 22 Dec 2014 00:33:20 -0800 (PST)
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 SJ5Pyng7iqJI for ; Mon, 22 Dec 2014 00:33:19 -0800 (PST)
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 AC6351A0068 for ; Mon, 22 Dec 2014 00:33:18 -0800 (PST)
Received: from [192.168.131.138] ([80.92.123.20]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MDi9C-1Y7wW52ETG-00HAyd; Mon, 22 Dec 2014 09:33:16 +0100
Message-ID: <5497D747.90701@gmx.net>
Date: Mon, 22 Dec 2014 09:33:11 +0100
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Rene Struik ,  "dtls-iot@ietf.org" 
References: <9E083D30-A338-4668-8B9A-1A6564E3623C@muada.com> <5492ECB3.90502@gmx.net> <5492FC10.3000204@gmail.com>
In-Reply-To: <5492FC10.3000204@gmail.com>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TtfJJ0vhLwW31962MEwkW2eR2mMFfdpbI"
X-Provags-ID: V03:K0:/yHhJKdJfCipDcdIj/qROTAtvkcD3wQu+Q5yC+CwozRR9xQLmCp JXwf0HKvEH7HQesQAQEgUX47yj08YwY3vEW9111zgUX8CmDdpnHye6chxJ/oixkPE1l6eTH AF3/ve4rFET/ve/Q/RgmOgYdLhgvp5cEEeZWK3FCDZCpJCC4wIER9XJRQbt4PdFup/m2yun qLG8JSNng6VpU2FsxRvdg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/27_OUyVAQSk4mlbVNOok5Jnm_So
Subject: Re: [Dtls-iot] Fwd: [Int-area] Quick MTU measurements
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, 22 Dec 2014 08:33:21 -0000

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

Hi Rene,

First, I believe the analysis by Iljitsch does not show an any IoT
deployments that use IEEE 802.15.4 radios (or IPv6 over similar low
power radios). Hence, he came to the conclusion that we pretty much have
an MTU size of at least 1280 bytes.

In many deployments the path MTU might well be the MTU of the link the
IoT device is attached to the network.

Why there aren't any low power radios showing up in this analysis is an
interesting question. There are probably a number of reasons, including
networks that are separated from the rest of the Internet (using
firewalls), few IEEE 802.15.4 network deployments, IPv6 over Bluetooth
Smart just getting started, many IoT deployments using IPv4 or radios
that are not low power, etc.

In context of our work there are a few questions:

* Is the recommendation to do a path MTU discovery before the DTLS
exchange meaningful? (Consider that the text below  preliminarily
concludes that 'IPv4 PMTUD is no longer used'.)

* Is there really a problem with overlapping fragments since you will
have to be prepared to buffer at minimum a DTLS message anyway and at
maximum an entire flight.

Ciao
Hannes


On 12/18/2014 05:08 PM, Rene Struik wrote:
>=20
> Hi Hannes:
>=20
> I was intrigued by the following snippet in your second pointer:
>=20
>     "With IPv6, if you want to send packets larger than 1280 bytes,
>     PMTUD is mandatory, as routers aren't allowed to fragment IPv6 pack=
ets."
>=20
> Does this have implications if the MAC layer only supports small frame
> sizes (such as 127 bytes with classic 802.15.4)?
>=20
> Best regards, Rene
>=20
>=20
> On 12/18/2014 10:03 AM, Hannes Tschofenig wrote:
>> Just got this mail; very timely.
>>
>> -------- Forwarded Message --------
>> Subject: [Int-area] Quick MTU measurements
>> Date: Thu, 18 Dec 2014 15:58:13 +0100
>> From: Iljitsch van Beijnum 
>> To: int-area@ietf.org
>>
>> Hi all,
>>
>> We had some discussions on MTU issues on the v6ops list, which prompte=
d
>> me to do some quick measurements, please see:
>>
>> Maximum packet sizes on the internet
>> http://www.bgpexpert.com/article.php?article=3D151
>>
>> Internet packet sizes part 2: IPv4 path MTU discovery is dead
>> http://www.bgpexpert.com/article.php?article=3D152
>>
>> Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they c=
an
>> handle at least 1280 bytes in their TCP MSS and about 65% can handle 1=
500.
>>
>> In almost a week, I didn't get a single IPv4 too big, so it seems that=

>> in practice, IPv4 PMTUD is no longer used. (Please confirm with a larg=
er
>> dataset before taking any actions based on this!) However, depending o=
n
>> PMTUD doesn't lead to obvious problems with IPv6.
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>>
>>
>>
>>
>> _______________________________________________
>> dtls-iot mailing list
>> dtls-iot@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtls-iot
>=20
>=20
> --=20
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>=20


--TtfJJ0vhLwW31962MEwkW2eR2mMFfdpbI
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

iQEcBAEBCgAGBQJUl9dHAAoJEGhJURNOOiAtSMIH/RGGue2pr3FDaAJsZYVXO/DK
PILG4J4GfZD+S6EM5ga+TDzI9TtrUm/oEnstMTdpjqyh1GXVp45rwkgdZ+qLU6OK
gjyniEEEU6iXTcOOpVkfDsH42OzCBHdi59+5HMQEYynyhmufn5cf/bH7cc838rtC
Gh8nWYPuhGAbjT8LvFrWvW3m1oW31drFyMfEMozOXlF6ZjS01/5iU6UKv6iCXf6H
6Y1/fIUsC2EyY4GUQ1/1IOTrU8xkU5QMcbP08NjxMgQn33b6VeLZkuhlN5ysybSX
LcU5GvaJMxMimvTA5WQLnFdnXaQ4ynToDKIoikhv8dcko6IV5/wiH+PnCoSz0Pw=
=hjgP
-----END PGP SIGNATURE-----

--TtfJJ0vhLwW31962MEwkW2eR2mMFfdpbI--