enable DTLS negotiation

[David Woodhouse]

On Fri, 2016-09-16 at 08:24 +0200, Nikos Mavrogiannopoulos wrote:
> 
> That would work, but would work very inefficiently for a server that
> likes to handle multiple clients. That is because, instead of the main
> process forwarding the sessions to the appropriate process/thread it
> would have to perform a half-handshake just to figure out to which
> process it should forward the connection. So it would be additional
> load for a process which is only destined to quickly serve and
> distribute... So not only it would be technically challenging but
> would have been sub-optimal as well.

You call it a 'half-handshake' but remember, it involves *no* crypto.
All it needs to do is generate a random number, pick its preferred
cipher from the ones on offer, and send the ServerHello{,Done}. 

(Note: I'm not suggesting we open-code that; I'm talking about the
computational complexity of what GnuTLS needs to do at this point in
the "quarter handshake" :)

>  That's why I'd like to move on
> with the dtls1.3 psk username indicator instead (which is brought to
> tls1.2 by draft-jay-tls-psk-identity-extension). We can implement it
> in openconnect as well, even now, as gnutls allows an application to
> register a custom extension, but still we would have to use a custom
> extension number (protocol is not registered to iana yet).

If we really can't make ocserv wait for a ClientKeyExchange, then I
think I prefer this option. It means there is a good chance that what
we do *will* end up being properly compatible with the final
standard¹. 

And if the psk-identity draft *does* change before release in a way
which makes it incompatible, we can cope with that too.

For now, the string (e.g. "PSK-NEGOTIATE") that we negotiate in our
X-DTLS-CipherSuite indicates specifically draft-jay-tls-psk-identity-
extension-01 with the "suggested" value 10015. It's basically a
private, but DTLS-based, protocol and that's perfectly reasonable.
That's basically what we're already doing already.

If the final RFC is sufficiently different to the current draft, then
we can introduce a new string to identify that protocol, which *will*
be "pure" DTLS.

(Actually, let's not use 'PSK-NEGOTIATE' since we currently use it to
mean something else. Let's call them... 'PSK-IDENTITY-01' and then
maybe in the future 'PSK-IDENTITY-RFCxxxx'  Or something like that.)

-- 
dwmw2

¹ The irony of this, in parallel with the pre-standard version of DTLS
  that we are *still* using after all these years, is not lost on me :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160916/75240489/attachment-0001.bin>