enable DTLS negotiation

[Nikos Mavrogiannopoulos]

On Thu, Sep 15, 2016 at 12:11 AM, David Woodhouse <dwmw2 at infradead.org> 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.

I don't think that's the case. The protocol as we have it can work
perfectly without draft-jay-tls-psk-identity-extension or the session
id hack we have. The reason we use the hack is to allow the server to
identify the first packet when it serves many clients, and DTLS
doesn't have a straightforward way to do that. We could put that value
over an existing extension (server_name, alpn), or we could re-use the
session ID field that the existing protocol also uses. I selected the
last approach because all of them were to modify a field that wasn't
designed for that, and it was the simplest for the server side (didn't
require the receive function to parse TLS extensions).

A change to a future capability is as simple as making an additional
function call.

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

I'm not sure about it. Yes, if you trust X-DTLS-MTU to give you an
accurate value then that could be something that will be missed.
However, there is no reason the server can make a better estimate of
the tunnel MTU than the client; in fact it is most likely as blind as
the client regarding the newly established tunnel. In addition the MTU
is not like a commandment the server can set (in stone or otherwise).
It can be different for sending or receiving (not common - but can
be), and it varies over time (e.g., a client roaming). That's why I
think that there is no reason to consider X-DTLS-MTU at all. The
client has the X-CSTP-Base-MTU value, which provides the server's idea
of the link MTU and can use it to do its necessary calculations.

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

I don't think it is just as simple and the costs are balanced. Just
consider how much time and work it took to add AES-GCM to the old
protocol. It was added in 2015-03-10 for openssl, and 2014-03-05 for
gnutls. It required two distinct implementations because adding it was
not straightforward. For gnutls it also required to enhance the custom
for openconnect gnutls_session_set_premaster() function to work with
TLS 1.2, adding tests etc. If we had the DTLS-PSK protocol in place
then none of all these would have been required and AES-GCM support
would just have been included with an upgrade of the crypto libraries
somewhere in 2011 and 2012.

So I really think that it is very costly to support and extend the
legacy DTLS negotiation.

> 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,

Isn't that already the case?

regards,
Nikos