enable DTLS negotiation

[David Woodhouse]

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>