[openssl-dev] DTLS encrypt-then-mac

[David Woodhouse]

... is broken in 1.1. We negotiate it, then don't actually *do* it.

https://github.com/openssl/openssl/pull/1705 contains a patch to
disable it unconditionally for DTLS, on both server and client.

In that same PR there's also a patch to actually implement EtM for DTLS
— so that if it ever *stops* being disabled, it would actually work.
That second patch is tested (by reverting the first) against a GnuTLS
server both with and without EtM.

What remains is to have a conversation about how, if ever, we can turn
EtM back on again.

There are a few mitigating factors:
 • OpenSSL 1.1 is the only version which has this problem.
 • OpenSSL 1.1 supports DTLSv1.2 and AEAD ciphers, which disable EtM.

However, the problem still exists for applications using OpenSSL 1.1
with DTLSv1.0, where they *will* end up using a CBC cipher.

I don't think it makes much sense just to leave EtM disabled —
depending on how you look at things, that's either not necessary (who
cares about OpenSSL 1.1.0[ab]; just upgrade to 1.1.0c!), or not
sufficient (1.1.0[ab] are still broken when talking to e.g. GnuTLS
anyway, and *everyone* would need to stop doing DTLS+EtM).

So I think in the process of typing this mail, I've persuaded at least
*myself* that the PR above should be refactored to include *only* the
second patch; to *fix* EtM without disabling it.

Any dissenting opinions?

It really would be nice to have a way to disable EtM voluntarily
though; especially for the DTLS_get_data_mtu() test cases that I've
added in PR#1666.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161013/9cece44d/attachment-0001.bin>