enable DTLS negotiation

Nikos Mavrogiannopoulos n.mavrogiannopoulos at gmail.com
Fri Sep 16 06:07:06 PDT 2016


On Fri, Sep 16, 2016 at 12:39 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>>  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.

Ok. For openconnect client it would be fairly easy to handle this,
only send an extension with fairly static data, as it only sends a
username. However, there is a catch, we should do that for both
openssl and gnutls. Ocserv would require to be able to parse the TLS
client hello since the extension data are in variable positions,
however that shouldn't be really hard. I could do the ocserv part and
the gnutls part if you do the openssl part :)

> (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.)

Let's not change it yet. Since we are experimenting let's keep it for
the current version of the protocol, and if we need again we change
it.

regards,
Nikos



More information about the openconnect-devel mailing list