On Thu, 2016-09-15 at 08:18 +0200, Nikos Mavrogiannopoulos wrote: > 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. Right. That's what I put in my footnote ? we're only really doing this to cope with the architecture of the server, which *really* wants to know from the first packet which client it's dealing with. If it wasn't for that, we could use the protocol as $DEITY intended. If I held a gun to your head? and *made* you change the whole forawrd_udp_to_owner() thing so that it *did* work with an unadulterated DTLS protocol and use the PSK identity in a ClientKeyExchange message... what would it look like? You'd probably send the ServerHello and ServerHelloDone messages from the main process, yes? And then when the ClientKeyExchange comes in, *then* you'd know which client it is. The problem, as you've said before, is that then the worker process needs to reconstitute the same server-side state from the nascent connection. Some parts are reproducible if you're careful (the choice of cipher). But then there's the Server Random field. Which really *does* have to be right :) But if you had a gun to your head, you *could* add an API to GnuTLS to allow that session state to 'reconstituted' in the worker process... perhaps the main process could just send over the UDP fd along with a copy of the full ServerHello packet that got sent. And then the new GnuTLS API would basically be "pretend *you* sent this", and GnuTLS would read the Server Random and other things from it. Such a new API probably wouldn't be any more horrid than the existing gnutls_session_set_premaster() hack we've already added for the benefit of OpenConnect, would it? And it would mean that we are using DTLS as $DEITY intended, with no hacks on the *wire* that have to live in perpetuity. And it would also mean that when?draft-jay-tls-psk-identity-extension comes along, it just silently works and the 'identity' really is what we're sending in it, just as we *were* sending that 'identity' in the ClientKeyExchange all along. > A change to a future capability is as simple as making an additional > function call. And if we're already *using* the PSK "identity" then maybe it's not even that... it's all just "natural". > > > > 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. Ah, OK. I hadn't realised X-CSTP-Base-MTU came back. Sure, let's amend the current patches to calculate the DTLS MTU according to that and the actual protocol+ciphersuite in use. That's just a case of using the existing dtls_set_mtu() function, right? Having taken off the IPv[46], UDP, and one-byte OC DTLS headers. > > 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. Hm, OK. I concede I was thinking of ChaCha20, which AIUI we added too *soon* before it was really ready, and had to disable. But yes, it *is* nicer to use the protocol as it was intended, and not reimplement the ciphersuite negotiation out-of-band. I'll go fix the client-side MTU setting. And I won't actually put a gun to your head but I'd *really* like to take a hard look at making ocserv cope without the session-id hack. -- dwmw2 ? tsk, promoting an attitude of violence again... -------------- 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/20160915/560e592b/attachment-0001.bin>
