Skip to main content

[jsr360-observers] [jsr360-experts] Re: DTLS server support

  • From: Lampart Thomas < >
  • To: " " < >
  • Subject: [jsr360-observers] [jsr360-experts] Re: DTLS server support
  • Date: Tue, 22 Oct 2013 17:46:29 +0200
  • Accept-language: de-DE, en-US
  • Acceptlanguage: de-DE, en-US
  • List-id: <jsr360-experts.jsr360.java.net>

Dear all,

Well, it would be a massive inconvenience for anybody who needs DTLS server 
as there is no easy way to just add this functionality in your midlet.
You would need a whole TLS stack (e.g. bounce castle) to do so. And then you 
have two TLS stacks in your system, both with their own mechanisms to handle 
certificates. Not nice.

best regards
  Thomas


From: Werner Keil 
[mailto: ]
Sent: Dienstag, 22. Oktober 2013 17:24
To: 

Subject: [jsr360-experts] Re: [jsr360-observers] DTLS server support

Thomas,

Thanks for your input. Especially from a European/German perspective it makes 
sense, see the slighly different approach to privacy here and in other parts 
of the World (not just US[cid:image001.gif@01CECF4E.A389F850])

As I mentioned, I'd hope if not in the Final release this could at least be 
done in an MR.
JSRs like JCache dropped entire functionality like Transaction support from 
its spec and deferred it to at least an MR or future version, too. Without 
going into detail about that here now, it seems a slightly smaller step from 
adding this to a CLDC MR than what 107 plans for transactions, or do you see 
a massive impact/inconvenience for users and developers in our case?

Thanks,
Werner

On Tue, Oct 22, 2013 at 5:13 PM, Lampart Thomas 
< <mailto: >>
 wrote:
Dear specleads, experts,

We have a different position there, because:

- Adoption of DTLS is not widespread
Yes, maybe today in a consumer world. However when you look at M2M and for 
example CoAP or what OMA does with lightweight M2M you will find that the 
usage of UDP is very common there. And to secure this you will need DTLS.

- For typical IoT and M2M use cases only the DTLS client side is needed
I don't agree. See next item.

- In a typical scenario you would establish a regular server socket and
  have the CLDC 8 application open a DTLS client connection to a DTLS server
  that runs on a gateway
And you do not see Java ME8 on this gateway ? Actually we do. The gateway 
could be our module. It talks coAP/UDP over some short range radio on the one 
side and HTTPS on the other side over 2G/3G. In this use case we would be the 
DTLS server.

- The implementation of a DTLS server is nontrivial
I don't think that this is more "nontrivial" than a TCP secure server. Sure 
it's some extra effort.


Not adding this now but in the next release (whenever this will be) would be 
very unfortunate from our point of view.

Best regards
  Thomas


From: Michael Lagally 
[mailto: <mailto: >]
Sent: Dienstag, 22. Oktober 2013 16:35
To: 
<mailto: >
Subject: [jsr360-observers] [jsr360-experts] DTLS server support

Dear JSR 360 EG members,

On a previous EG call It has been suggested to include support for a DTLS 
server into GCF.

We discussed the DTLS server support internally quite extensively.

The feedback we got was:

- Adoption of DTLS is not widespread
- For typical IoT and M2M use cases only the DTLS client side is needed
- In a typical scenario you would establish a regular server socket and
  have the CLDC 8 application open a DTLS client connection to a DTLS server
  that runs on a gateway
- The implementation of a DTLS server is nontrivial

Taking all this into account it is our position that it is unnecessary to add 
DTLS server support
to the current CLDC8 spec, rather consider it in a future version of the spec.

Best regards,

Michael+Roger



________________________________
This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for 
the message if altered, changed or falsified. If you are not the intended 
recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a 
transmitted virus


________________________________
This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for 
the message if altered, changed or falsified. If you are not the intended 
recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a 
transmitted virus

GIF image



[jsr360-observers] [jsr360-experts] DTLS server support

Michael Lagally 10/22/2013

[jsr360-observers] [jsr360-experts] Re: DTLS server support

Werner Keil 10/22/2013

[jsr360-observers] [jsr360-experts] Re: DTLS server support

Lampart Thomas 10/22/2013

[jsr360-observers] [jsr360-experts] Re: DTLS server support

Werner Keil 10/22/2013

[jsr360-observers] [jsr360-experts] Re: DTLS server support

Lampart Thomas 10/22/2013

[jsr360-observers] [jsr360-experts] Re: DTLS server support

Michael Lagally 10/23/2013
 
 
Close
loading
Please Confirm
Close