Subject: Re: Eric Rescorla's Discuss on draft-ietf-httpbis-encryption-encoding-08: (with DISCUSS and COMMENT)

From: "Manger, James" <[email-masked]>
Date: Thu, 13 Apr 2017 05:31:37 +0000

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Apr 2017 05:49:52 -0700

On Wed, Apr 12, 2017 at 10:31 PM, Manger, James <
[email-masked]> wrote:

> 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