enable DTLS negotiation

[David Woodhouse]

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>