- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 24 Jan 2017 08:37:51 +0900
- To: "Manger, James" <James.H.Manger@team.telstra.com>
- Cc: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 23 January 2017 at 21:47, Manger, James <James.H.Manger@team.telstra.com> wrote: > A padding byte to distinguish intermediate and final records could indeed work. I like it. You can pad an arbitrary amount and you only pay one octet per record overhead if you don't like padding, and the trailing record requirement goes away. > It doesn't consume any extra bytes in this scheme as it piggy-backs on an end-of-padding byte. But in a different multiple-AEAD-record scheme that didn't offer padding (a nice, but not strictly necessary feature) it wouldn't be so ideal. I've seen ideas to put the first-vs-intermediate-vs-last indicator in the nonce, in the KDF, in the AAD, in the record length, and now in the plaintext. I'm not sure how to pick. I believe that it doesn't matter. > What do you do if last non-zero byte isn't 0x01 or 0x02? Explode and discard the data - it's corrupted. If we don't require that, then an attacker gains a decryption oracle. (Same reason for requiring that the padding be fixed in size.)
Received on Monday, 23 January 2017 23:38:24 UTC