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.
