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
