- From: Manger, James <James.H.Manger@team.telstra.com>
- Date: Tue, 24 Jan 2017 00:10:55 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>>>> So I would support a padding scheme similar to TLS 1.3: <content><non-zero byte><zeros…>. >>> Furthermore, if the nonzero byte was 0x01 for non-final blocks and 0x81 for final block (or any two different nonzero values), then that would also solve the truncation flaw from last message, no? >> 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. If we go with this approach, we should also distinguish the 1st record. For instance, for the end-of-padding byte: * Set bit 8 * Set bit 1 if this is the first record * Set bit 2 if this is the last record So 0x81 indicates the 1st of multiple records; 0x83 indicates a message with only a single record (first is also last); 0x82 indicates the last of multiple records; 0x80 indicates an intermediate record; 0x00 is padding, keeping looking back for the end-of-padding byte Any other value indicates an error. -- James Manger
Received on Tuesday, 24 January 2017 00:11:38 UTC