- From: Martin Thomson <mt@lowentropy.net>
- Date: Fri, 21 Nov 2025 09:48:43 +1100
- To: rfc-editor <rfc-editor@rfc-editor.org>, "Martin Thomson" <martin.thomson@gmail.com>, httpbis-ads@ietf.org, "Mark Nottingham" <mnot@mnot.net>, "Tommy Pauly" <tpauly@apple.com>
- Cc: patrick@psbarrett.com, ietf-http-wg@w3.org
I was unable to decrypt Patrick's alternative using the keys from the specification, but I suspect that this is incorrect, similar to the other erratum. The first record decrypts correctly (padding 0x0100). The second does not. I suggest that we REJECT this also. On Fri, Oct 31, 2025, at 07:31, RFC Errata System wrote: > The following errata report has been submitted for RFC8188, > "Encrypted Content-Encoding for HTTP". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8621 > > -------------------------------------- > Type: Technical > Reported by: Patrick Barrett <patrick@psbarrett.com> > > Section: 3.2 > > Original Text > ------------- > HTTP/1.1 200 OK > Content-Length: 73 > Content-Encoding: aes128gcm > > uNCkWiNYzKTnBN9ji3-qWAAAABkCYTHOG8chz_gnvgOqdGYovxyjuqRyJFjEDyoF > 1Fvkj6hQPdPHI51OEUKEpgz3SsLWIqS_uA > > Corrected Text > -------------- > HTTP/1.1 200 OK > Content-Length: 74 > Content-Encoding: aes128gcm > > uNCkWiNYzKTnBN9ji3-qWAAAABkCYTHOG8chz_gnvgOqdGYovxyjuqRyJFjEDyoF > 1Fvkj6hQPdPHfNE6ZBBGizjWQMll3XVvzJ8 > > Notes > ----- > This is the same issue as Erata ID 8620 > (https://www.rfc-editor.org/errata/eid8620), but for the next example. > > This one I'm less sure about. The RFC never explicitly says whether the > final padding delimiter is required or not, but, by my reading at > least, does strongly imply it is required in several places. > > Assuming the final padding delimiter is required, this example should > include it. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8188 (draft-ietf-httpbis-encryption-encoding-09) > -------------------------------------- > Title : Encrypted Content-Encoding for HTTP > Publication Date : June 2017 > Author(s) : M. Thomson > Category : PROPOSED STANDARD > Source : HTTP > Stream : IETF > Verifying Party : IESG
Received on Thursday, 20 November 2025 22:49:10 UTC