[TLS] Simpler encrypted headers for DTLS (and TLS)

[Bryan A Ford <[e-mail]>]

While I think the approach I suggested for encrypted DTLS headers would
work, it does have the downsides of (a) the complexity of managing the
hash table of encrypted sequence numbers, and (b) the risk of
desynchronization after long bursts of missed packets.

But further discussion with Philipp Jovanovic led me to the realization
that the simplest and cleanest solution in the DTLS case would simply be
to rely on AEAD ciphers that either support "secret message numbers" or
have a "misuse-resistance" property.  In particular:

- Secret message numbers basically do "precisely what DTLS needs",
namely allow a message/record/sequence number to be transmitted under
encryption along with the AEAD payload.  Secret message numbers are
specified as an optional feature for AEAD submissions to the ongoing
CAESAR cipher competition (see
http://competitions.cr.yp.to/caesar-call.html), and further elaborated
in this useful message by DJB in 2013:

	https://groups.google.com/forum/#!searchin/crypto-competitions/secret$20message$20numbers/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J

- Another optional feature that some CAESAR competition submissions
have, and *all* are required to document one way or another, is
"misuse-resistance".  In particular, a misuse-resistant AEAD does not
rely on nonce uniqueness for security.  With a misuse-resistant AEAD
(which we might alternatively just refer to as a "nonceless AEAD"), you
can simply move the complete DTLS header from the additional_data field
into the plaintext, and leave the sequence number out of the nonce.  The
sequence number will still be in (encrypted) header and thus available
for replay-protection purposes and such, and will automatically ensure
that all DTLS plaintexts (and hence all resulting ciphertexts) are
cryptographically unique.

I'm not proposing necessarily that the "next version of DTLS"
(presumably based on TLS 1.3) should *only* allow AEADs that support
secret message numbers or misuse-resistance.  Rather, I'm proposing that
the next DTLS should support at least one such cipher, and that when
DTLS negotiates such a cipher, it simply takes advantage of the relevant
property to move the DTLS header under encryption.

So the upshot is that simply "using relevant AEAD features when
available" would seem to take care of the DTLS case completely, with no
special fuss or additional complexity.  Which means that we can focus on
the TLS case now, without worrying about whether and how easily it will
translate to DTLS.

And given that, for the TLS case I'm inclined to prefer my second
proposal, namely just reinterpreting the "length" field to be a
"next-record-length" field.  This requires no special mucking with the
AEAD in TLS either, and no extra complexity at all in TLS
implementations that pad to constant record sizes (which I hope many will).

For reference, some background pointers misuse-resistant ciphers
(definitely not comprehensive):

- https://eprint.iacr.org/2006/221.pdf
- https://eprint.iacr.org/2015/999.pdf

Cheers
Bryan