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>
