- From: Manger, James <James.H.Manger@team.telstra.com>
- Date: Thu, 13 Apr 2017 05:31:37 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <MEXPR01MB160767A203EFDBAA13F6B9A3E5020@MEXPR01MB1607.ausprd01.prod.outlook.com>
Eric said: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The "aes128gcm" content coding uses a fixed record size. The final encoding consists of a header (see Section 2.1) and zero or more fixed size encrypted records; the final record can be smaller than the record size. This restriction seems to be an artifact of your previous design which used short records as an end marker. With the new padding delimeter structure (which I note is isomorphic to the TLS 1.3 structure), I'm not seeing any reason to require that the records be fixed length (as they are not in TLS). I didn't see any discussion of this point in the thread where this structure was designed, so I'd like to get confirmation that the WG considered this point and decided to continue with the above restriction. I'll clear this discuss upon either such confirmation or removal of the restriction. ---------------------------------------------------------------------- The fixed record size is also necessary to be able to split the body into records. Records are simply concatenated together. There are no other boundary markers or per-record size fields. The fixed size allows you to read the header then skip, say, 1 MB into the content and still determine where the next record is so you can recover authentic plaintext from that point (though due to unknown padding in earlier records you might not know the actual offset for this plaintext). -- James Manger
Received on Thursday, 13 April 2017 05:32:20 UTC