W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 14 Apr 2017 05:49:52 -0700
Message-ID: <CABcZeBNM7tJK6ihGMYAYgxZtpX-esFwzOT+3u9Ty--R41FPhpg@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC