Re: Binary packet protocol rethink

Bryan Ford <[email protected]> writes:

> It’s hard for me to see how separately authenticating the length field
> would be a benefit; in fact I would worry about whether it could
> introduce a weakness, e.g., where an attacker could somehow contrive
> “mix-and-match” attacks

I'm also not sure there's a real benefit. If we do it, the length and
payload data must be securely linked together. E.g., using a single
incrementing sequence of nonces. And it *may* be worthwhile to do
something with a short and therefore relatively weak authentication tag.

> Thus, changing the header encoding while leaving the authentication
> and body-encryption unchanged from standard AEAD practice cannot make
> security any worse than just transmitting the header (AD part) in
> cleartext, and can (sometimes) be a security benefit.

This is a clear argument. For this to hold, it's crucial that the length
encryption and the payload encryption are independent. In SSH, there's
been subtle problem when encrypting length and payload together using
CBC (I don't quite grasp the fine details, but there have been
references posted to the list recently).

> SSH, which did something like this, ran into trouble with attackers
> being able to twiddle the record length field to make the record length
> look big, causing the receiver to try to receive a very large record,
> and hence appear to the user to hang,

I don't think we have had this particular problem; any reasonable ssh
implementation ought to disconnect with a protocol error if the length
is unexpectedly large. Lengths are maximum 32K (unless both ends have
negotiated something different, which I think is rare).

There have been problems, but of a more subtle kind. Like observing when
and how the other end disconnect to get partial information about the
decryption, and in addition, infer information about the preceding
cleartext block thanks to the CBC relation.

> The conceptually simplest approach I can think of: In the specification
> of how AEAD nonces are generated (section 5.2.2 of
> draft-ietf-tls-tls13-07), reserve the least-significant bit of the
> record sequence number, so that sequence numbers increment by 2 rather
> than 1 each record.  Thus, we get two unique nonces per record from the
> same set of symmetric keys.  We first use the nonce with a '0'
> least-significant bit to perform the regular AEAD-encryption of the
> record with the header info as additional_data.

I think I'd use them in the opposite order (to get the sequence numbers
in processing order; one has to process the lengths first, in particular
on the decryption side), but that's a very minor detail.

I like the alternating nonces idea.

> Then for the same record we use the nonce with a '1' least-significant
> to AEAD-encrypt a sequence of five zero bytes ("\0\0\0\0\0"), and use
> the first five bytes of result as the cipherstream to XOR the 5-byte TLS
> header with before transmitting.

I think AEAD constructions of practical importance generate a key stream
and xor it to the plaintext. In which case your proposal (as I'm sure
you intended) boils down to generating a key stream with a different
nonce than for the payload.

Not sure if doing a "general" construction on top of an arbitrary AEAD
is useful; the alternative would be to leave the details to the
specification of any particular aead suite.

We're kind of ending up with "authenticated encryption with auxillary
authenticated data and auxillary encrypted data". That's going to be a
really awful acronym.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.