enable DTLS negotiation

[Nikos Mavrogiannopoulos]

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

That would work, but would work very inefficiently for a server that
likes to handle multiple clients. That is because, instead of the main
process forwarding the sessions to the appropriate process/thread it
would have to perform a half-handshake just to figure out to which
process it should forward the connection. So it would be additional
load for a process which is only destined to quickly serve and
distribute... So not only it would be technically challenging but
would have been sub-optimal as well. That's why I'd like to move on
with the dtls1.3 psk username indicator instead (which is brought to
tls1.2 by draft-jay-tls-psk-identity-extension). We can implement it
in openconnect as well, even now, as gnutls allows an application to
register a custom extension, but still we would have to use a custom
extension number (protocol is not registered to iana yet).

regards,
Nikos