Re: Binary packet protocol rethink

[Bryan Ford <[e-mail]>]

In followup to my own message…

On 30 Nov 2015, at 14:58, Bryan Ford <[e-mail]> wrote:
> On 30 Nov 2015, at 12:34, Niels Möller <[e-mail]> wrote:
>> Simon Tatham <[e-mail]> writes:
>> 
>>> an attacker either guesses the true length by correlating to the
>>> TCP headers, or probes it by means of the byte-at-a-time dribbling
>>> attack, or actively corrupts the cipher block containing the length and
>>> waits to see when the resulting MAC failure is reported, 
>> 
>> Would you be happier if the length field were independently
>> authenticated? I'm not sure how strong an authenticator we need, it
>> seems a bit silly to use an authentication tag which is much larger than
>> the message, but maybe it's really needed.
> 
> It’s hard for me to see how separately authenticating the length field would be a benefit; […]

Sorry, on further thought I *do* see now what might be gained in principle by authenticating the length field separately, and how that might be implemented securely.  So the SSH record stream might for example alternate between fixed-size “length records” and variable-size “payload records”, each with its own AEAD MAC.  To ensure no mix-and-match vulnerabilities this distinction must be encoded in the AEAD nonce: e.g., the least-significant bit might always be 0 for the length record and 1 for the corresponding payload record.  The cost is the space overhead of two MACs per “useful” payload record rather than just one, but the benefit is the receiver obtains certainty that an attacker can never trick the receiver into trying to read a different-length (e.g., longer) block than the sender intended.  That would indeed be nice, and I can see it potentially being worth the cost.

Just to brainstorm a bit further, here’s a different variant that might mitigate the space cost somewhat.  In every record, include a length field that indicates the length of the *next* record.  Then when the sender has a batch of records to transmit, it can just send them consecutively with one MAC per record.  But when the sender is about to go idle, i.e., is transmitting the last record in a batch for which the sender doesn’t “already” have a subsequent record immediately ready to go, the sender sets the next-record-length field to some standard minimum size.  The sender can then go idle; the receiver will wait for that minimum-size next record.  When the sender has something to send again, it sends the promised minimum-length record, which might contain no useful data but merely get the pipeline going again, with a next-record-length field appropriate for whatever the sender actually wants to send next.  So this way the protocol actually pays the bandwidth cost of extra MACs only when the stream goes idle, not on every record.

This design direction does seem attractive in some ways.

Bryan