Subject: Secdir last call review of draft-ietf-httpbis-binary-message-04

From: Daniel Migault via Datatracker <[email-masked]>
Date: Wed, 01 Jun 2022 06:58:43 -0700

Reviewer: Daniel Migault
Review result: Ready

Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

abstract:

""" As such, this format is unlikely to be suitable for applications that
depend on an exact recording of the encoding of messages."""

I am wondering what it actually means. Typically, I do not see much differences
between the content provided by bmessage and message. For my own information,
in case a response is compressed I am wondering if the compression would occur
"over" the bmessage or if the bmessage would include the compressed content.

Section 3.

I have the impression item 2 of the list could be more consistent with the
other items that is starting with 2. interim response. By the way wouldn't
informational response more appropriated ?

Section 4

   This document describes a number of ways that a message can be
   invalid.  Invalid messages MUST NOT be processed except to log an
   error and produce an error response.

The message seems to be at least processed to determined it is invalid. I
believe what we are trying to say here is that the message must not be passed
to the application or must be discarded as soon as it is detected to be invalid.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 Jun 2022 10:12:48 +1000

Hi Daniel,

Thanks for the review.

> "over" the bmessage or if the bmessage would include the compressed content.

There are no (or at least no significant) *semantic* differences, but there are great differences in *encoding*.  For some applications, capturing the precise encoding is considered important.  Archival and security applications are two obvious ones.  For instance, WARC is fairly good at capturing this information.

We discussed the potential for this to capture capture HTTP/2 messages with all their header compression, framing boundaries, and other details but decided that this was not the goal of this format.  For one, trying to capture those details would greatly alter the efficiency and simplicity of the encoding.

So this is simply an statement of limited applicability: we capture semantics, not encoding.  I had hoped that was clear through the use of "exact recording of the encoding of messages".

As for compression, it is possible to compress a binary message (if you send one over HTTP, you can use a compressed content coding), but the format itself has no compression - or the ability to capture what compression was used in a message that the binary message might have been produced from.  The content of a binary message might also use a content coding, but that is just a native feature of HTTP that comes for free when you convey HTTP semantics.

> informational response more appropriated ?

It's informational.  I don't know how I keep making that mistake.  Tacked onto an open pull request (which fixes another instance of the same error).

> to the application or must be discarded as soon as it is detected to be invalid.

True:

Invalid messages MUST NOT be processed ++further++ except to log an error and produce an error response.