On Wed, 2016-07-27 at 12:09 +0200, Nikos Mavrogiannopoulos wrote: > On Wed, Jul 27, 2016 at 12:01 PM, Nikos Mavrogiannopoulos > <n.mavrogiannopoulos at gmail.com> wrote: > > This patch set enhanced the openconnect client to negotiate DTLS with > > ocserv. This will allow in the future the usage of DTLS 1.3 as well as > > any new ciphersuites without code changes. > > As this is WIP, any updates will be at: > https://github.com/nmav/openconnect-mine/tree/dtls-psk I've updated it and made it work for OpenSSL, at https://gitlab.com/dwmw2/openconnect/commits/dtls-psk However, I'm still vaguely unconvinced that it's worth it. Until draft-jay-tls-psk-identity-extension happens we *still* have to abuse the session resume protocol to tell the server who we are?, so it's not like it's now a perfect implementation of the DTLS protocol. And the current DTLS support allows the server to *know* the DTLS overhead and give an accurate X-DTLS-MTU in the connect response, while negotiation will make it vary. Even in your initial version with the ciphersuite fixed to the TLS ciphersuite, newer DTLS versions could have changed the record overhead for that *same* ciphersuite so it was impossible to predict. So we gain the flexibility of the negotiation on the wire... but so far that only really has a *cost* (no longer knowing the MTU) and the only benefits to it are theoretical ? newer DTLS versions might have fixes. And remember, we can support newer DTLS versions and ciphersuites *anyway*; it's just that we'd have to manually add them to the list. So I'm kind of ambivalent. If you want to make the server return an X-DTLS-Base-MTU header with the minimum of its own idea of, and the client's provided base-mtu values, and if you want to make the GnuTLS and OpenSSL clients both subtract the overhead of the *negotiated* DTLS protocol/ciphersuite from that, then I suppose I can live with it. -- dwmw2 ? Actually, we don't *have* to; strictly speaking that's just working ? around a limitation of the ocserv implementation?where it *wants* to ? know from the very first packet. Using the ClientKeyExchange would be ? the "right" way to do it according to the protocol, but is too late ? for ocserv's central dispatcher. -------------- 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/20160914/020ccfc2/attachment.bin>
