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: 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

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