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
