concerning the addition of chacha20-poly1305

[Nikos Mavrogiannopoulos]

It seems that the final draft of chacha20-poly1305 for TLS will not
contain the RSA ciphersuites, and these are used for the trick that
anyconnect does with the premaster secret in DTLS. The solutions which
are available are:

1. Keep 0e09ba35c1402d70f611a9530811f4834982758c, and switch the RSA
-chacha20 to PSK-chacha20 ciphersuites, and still use the premaster
secret hack. That would be (IMO) a quite terrible hack as it would make
the mapping of ciphersuites quite arbitrary, but things will work as
soon as possible and with minimal cost in code lines. It would,
however, make maintenance hard in the near future as new algorithms are
being added, as well as it would keep our inability to switch to a
newer DTLS version once out.

2. Switch to PSK ciphersuite negotiation for the openconnect
ciphersuite extensions, with the rule that the same cipher/mac
combination used for TLS will be used for DTLS. That's a fairly simple
scheme that is future proof and will allow for DTLS version negotiation
and other extensions (e.g. Encrypt-then-MAC for CBC).

3. Switch to ESP over UDP for our ciphersuite extensions, with the rule
that the same cipher/mac combination used in TLS will be used for DTLS.
That is as clean as above, and has the added advantage (in server side)
that we can use the ID header of ESP to detect the client changing the
src UDP port due to a NAT (it's a very common situation which breaks
UDP connect() and currently the ocserv uses the client IP to
reassociate the sessions --a practice which will not work if you have
more than one clients from the same IP). (*)

The last two options, will swift the protocol to something like
openconnectv2 which will be backwards compatible with the anyconnect
clients, although these clients will not be able to use our new ciphers
(something that anyway is the case also with 1). So, the question is,
which path should we take? I could sent patches for any of these
options reasonably soon.

In all cases, we would need to revert
0e09ba35c1402d70f611a9530811f4834982758c for the moment as the
ciphersuites it relies on will be dropped from gnutls.

regards,
Nikos

(*). For keying and re-keying instead of exchanging the key over TLS we
can derive it using gnutls_prf() the same way SRTP keys itself from
TLS. In the ESP case rekey would be done in parallel with the TLS
rekey, once done in TLS we derive the new ESP key and switch to it.