Subject: [Dtls-iot] Fwd: I-D Action: draft-mglt-dice-ipsec-for-application-payload-00.txt

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Jul 2014 22:39:08 -0400

To stir the pot a little bit on draft-keoh-dice-multicast-security, Daniel and I have written a short straw man draft to show how the same objective can already be achieved using existing widely deployed standards-track protocols.  This is a little less efficient, but does the job.  (Further efficiencies could be achieved by compressing away some of the redundant information, see the draft for some ideas.)

Thanks to Daniel for being available on short notice for this little mischievous act.

I’m no longer sure I don’t actually want to use this.

Grüße, Carsten

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-mglt-dice-ipsec-for-application-payload-00.txt
> Date: 23 Jul 2014 22:23:51 -0400
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : IPsec/ESP for Application Payload
>        Authors         : Daniel Migault
>                          Carsten Bormann
> 	Filename        : draft-mglt-dice-ipsec-for-application-payload-00.txt
> 	Pages           : 9
> 	Date            : 2014-07-23
> 
> Abstract:
>   This document is a strawman specification describing how IPsec/ESP
>   could be used to secure application payloads, in particular to enable
>   multicast applications where DTLS would be used for unicast.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mglt-dice-ipsec-for-application-payload/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-mglt-dice-ipsec-for-application-payload-00

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 24 Jul 2014 11:04:08 +0000

Thanks Carsten and Daniel for the quick draft. Indeed IPsec could have been a candidate if we did not have the initial goal of reusing as much of DTLS codebase  for the various IoT security operations.

Just a quick question, since you are using AES-CCM, how do you ensure different nonces for the different senders in your scheme?

regards
Sandeep

Sent from Windows Mail

From: Carsten Bormann<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎July‎ ‎23‎, ‎2014 ‎10‎:‎39‎ ‎PM
To: [email-masked]<mailto:[email-masked]>

Grüße, Carsten

> http://tools.ietf.org/html/draft-mglt-dice-ipsec-for-application-payload-00

_______________________________________________
dtls-iot mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________
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 reproduction 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.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jul 2014 08:35:50 -0400

> Just a quick question, since you are using AES-CCM, how do you ensure different nonces for the different senders in your scheme?

We haven’t said how the IV is built that RFC 4309 requires.  This could be done in a similar way draft-keoh-dice-multicast-security does this (e.g., starting with an 8-bit sender-ID).  Ensuring uniqueness of the sender-ID during the lifetime of the key of course is paramount.

Grüße, Carsten