[security-dev 00062]: Re: DTLS design

[Christian Uebber]

A separate reliable UDP transport class/channel is obsolete.  
Retransmission and fragmentation can be handled transparently by an  
updated version of SSLEngine's  Handshaker using regular unreliable  
DatagramChannels for transport. My first sketch was a little hasty.

I've started coding on a copy of SSLEngineImpl called DTLSEngineImpl.  
In the end I should be able to merge the changes almost seamlessly  
into SSLEngineImpl, though. But threading issues need careful testing  
first.

As it turned out SSLEngine's class diagram is not as transport  
independent as I'd have liked. SSLEngines are created through  
SSLContexts (which are also reusable for DTLS), which still have some  
dependencies to SSLSockets. I'm planning to return null in those cases.

Right now I'm still figuring out how to get a call to  
SSLContext.getInstance("DTLS") connected to the correct setup of my  
own code's classes for DTLS. The backend classes contain less comments  
and some legacy workarounds which make it harder to read. But I'm  
getting there.

I'll keep you updated...

Christian

Am 29.01.2008 um 14:56 schrieb Christian Uebber:

> I've finished a first sketch. The application knows about when the  
> engine is handshaking by checking SSLEngineResult.HandshakeStatus.  
> All we need to do is to provide a reliable UDP transport class  
> (including fragmentation and reassembly) as defined in the DTLS  
> spec, which MUST be used for transporting when the engine is not in  
> the state of NOT_HANDSHAKING. Anything else could be seamlessly  
> integrated into SSLEngine.
>
> It would be nicer if this transport class wasn't specific to DTLS as  
> current and future connectionless protocols could provide comparable  
> features, but for DTLS 1.0 compliance I don't see a better way right  
> now. We are not forced to make this specific class mandatory, so  
> future implementations could just plug in alternatives when the  
> standard evolves.
>
> Christian