- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 14 Apr 2017 05:49:52 -0700
- To: "Manger, James" <James.H.Manger@team.telstra.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CABcZeBNM7tJK6ihGMYAYgxZtpX-esFwzOT+3u9Ty--R41FPhpg@mail.gmail.com>
On Wed, Apr 12, 2017 at 10:31 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > 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). > OK, I somehow forgot that. I will clear my discuss. -Ekr > > > > > -- > > James Manger > > >
Received on Friday, 14 April 2017 12:51:07 UTC