Bug 1427675 - Short header for DTLS 1.3, r=ekr

Summary:
The code changes here are relatively straightforward, though there are a few changes of note:

* To make read and write more consistent, I changed `seqNum` on ssl3CipherSpec `nextSeqNum`.  The write side didn't change, but the read side previously saved  the last sequence number in that slot.  This makes the sequence number recovery  simpler and makes the code easier to reason able as a whole.

* SSL3Ciphertext now it holds the raw header and no longer has a type field. Passing the raw header through allows ssl3_HandleRecord and the functions that it calls to recover the sequence number.  I considered doing the recovery in   the gather functions, which used to recover the sequence number, but they don't have access to the cipher spec.

* Record construction now works in order: the header is written out first, with the length filled in after encryption.  This uses sslBuffer in a way more consistent with other functions.

* The hack where a cText of NULL was passed to ssl3_HandleRecord in order to have it handle the outstanding handshake message from the receive buffer was removed.

In addition to teaching TlsRecordFilter about the agent that it is operating with (in a separate CL), there are several changes to tests:

* We previously relied on the epoch and sequence number being properly encoded for DTLS records, so the sequence number reconstruction (used when we decrypt and re-encrypt) was invalid.  I restored the epoch to this field when doing DTLS.

* TlsRecordHeader no longer stores the wire format of the version, it includes a variant and non-wire version.

* TlsRecordHeader needs to know whether it is parsing DTLS 1.3, so TlsRecordFilter passes that info to it after asking the agent.

* TlsRecordHeader writes out DTLS 1.3 records in the 7 octet form always.  It can read the 2 octet header, using logic similar to that used by the main code, but it won't ever write that form.

* TlsAgentTestBase::MakeRecord also writes the 7 octet header.

* I parameterized the record drop tests so that I could test out of order delivery and various patterns with the short header.  This revealed some issues, including one good one.  I had a neat underflow bug that can happen near zero, which leads to ridiculously large sequence numbers being incorrectly assumed by a receiver.

This includes fuzzing-specific changes to account for the fact that fuzzing operates at the record layer, which is inconvenient for this change.  Ideally, we should change the fuzzing code so that only the core cipher parts are changed (that is, ssl3CipherSpec->cipher and ssl3CipherSpec->aead).  That will have to wait for another day.

Reviewers: ekr

Reviewed By: ekr

Bug #: 1427675

Differential Revision: https://phabricator.services.mozilla.com/D554

0 files changed, 0 insertions, 0 deletions