[security-dev 00051]: DTLS design

[Christian Uebber]

Dear Andreas,

due to some other current business my DTLS efforts were set back for a  
couple of weeks. But I'm happy to be back on the task now. First I'd  
like to discuss some architectural issues. I have put much time into  
working out the best way of integrating DTLS into the current APIs as  
transparently as possible. All solutions have specific trade-offs.

The main class most users would use is going to be TLSDatagramSocket  
extending the well known DatagramSocket. The first design choice would  
be - DTLS differentiates between client and server - if we should keep  
an unified DatagramSocket class without a dedicated  
DatagramServerSocket. I would say yes and I think that's an easy one.  
Users shouldn't be forced to understand different Java networking  
concepts if all what is added is an additional security layer. There  
are also sessions to be managed, but this is also possible in a  
transparent way without a dedicated server class. For security reasons  
a method as acceptHandshakeRequests(boolean b) could be added to  
enable or disable server like behavior.

In any case threads accessing the main I/O methods send(DatagramPacket  
p) and receive() should never be blocked by security layer events, as  
they are needed for bulk transfers from and to anywhere at any time.  
Of course there must be mechanisms (e.g. callbacks) for users wanting  
extended control.

TLS over TCP could attach session information to created sockets in a  
1:1 relationship. As we have just one (TLS)DatagramSocket socket for  
any potential endpoint (1:n) this cannot be done easily in the case of  
UDP. Since Java programmers never had to care about anything else but  
single DatagramPackets in their application space, this shouldn't  
change for anybody who doesn't need to deal with cryptographic  
details. So my proposal would be letting sessions be managed by the  
socket, but exposing control to those who need it.

Trying to accomplish full transparency on the receiving side is quite  
easy. All packets for which there is no established session object and  
which are not handshake requests are silently dropped. Handshake  
requests instead get forwared to a Handshaker class, packets belonging  
to an established session get unwrapped and are then fired through the  
send-method of the attached TLSDatagramSocket.

Transparency on the sending side implies some trade-off decisions in  
cases where the send-method gets packets for destinations without an  
already established session.

Full Transparency:
Session initiation is started, packets for an unestablished target are  
buffered until the session is established and then sent (or dropped if  
establishment failed).
Session initiation is started, packets get dropped (nobody promised  
that UDP would be reliable).
Manual Session Initiation: A method as initiateSession(InetAddress a,  
int port, CallbackHandler c) must be called before any packet can be  
send to a specific endpoint.

Buffers could fill up quite quickly under heavy load in the case of  
1.1. In the case of 1.2 no promises are broken, but it's not really  
good style. An average handshake can take a second and a lot of  
packets can already be lost during this time. The case No. 2 wouldn't  
be usable as a drop-in replacement anymore.

Maybe some aspects could be combined for the best solution. What do  
you think?

But that should be it for today... I'm looking forward to your remarks.


Christian


PS	I've emailed the signed SCA today. It should get registered soon.


Am 30.11.2007 um 02:42 schrieb Andreas Sterbenz:

> Christian Uebber wrote:
>> Is anybody already working on this for Java DatagramSockets? I'd be  
>> interested in doing the work. Integration into and reuse of the  
>> existing JSSE code would also be my preferred way to go.
>
> That sounds like a great idea. We at Sun don't have any current  
> plans to implement DTLS due to a lack of resources, but we could  
> assist by answering questions about JSSE or commenting on your code.  
> There are also some architectural issues about fitting a secure  
> datagram transport into the current Networking APIs that we may want  
> to discuss.
>
> BTW, you may want to look into signing the contributor agreement: http://openjdk.java.net/contribute/
>
> Andreas.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20080126/4d77c776/attachment.htm>