Httpdir last call review of draft-ietf-lamps-rfc6712bis-07

Reviewer: Lucas Pardue
Review result: Not Ready

I reviewed draft-ietf-lamps-rfc6712bis-07 on behalf of the HTTP directorate.

Summary

This document combines two past documents, RFC 6712 and RFC 9480, obsoleting
them and adding a SHOULD requirement for HTTP requests to use a Content-Length.
As such, the design elements have a legacy, which makes judging the HTTP
aspects a little trickier than if this was a new protocol being cut from whole
cloth. I make the following comments based on best practice for how a new
protocol would do things, these may not be feasible given the legacy but I
would appreciate the authors considerations about what is possible. I think the
document is on the right track but there are issues related to HTTP versions
that need to be resolved before the document is ready.

Major issues:

1. Section 3.1 HTTP Versions

The section states

> Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support HTTP/1.1
[RFC9112].

I appreciate that this text is taken directly from RFC 6712 but I want to ask
if there was any discussion about HTTP versions in the LAMPS WG. RFC 6712 was
published in 2012 and in the meantime there have been 2 revisions of the
HTTP/1.1 defintion, 2 major versions of HTTP added, and a refactoring of the
HTTP document family to clearly present common HTTP semantics separate from
wire-specific versions.

The requirement for supporting HTTP/1.0 is particularly concerning. This
document is on the Standards Track as a proposed standard. RFC 1945 is an
Informational draft that is not receiving any maintenance. It is effectively
lost in time and uses terminology that does not reflect the state of the HTTP
ecosystem. Furthermore, it has differences particularly wrt to redirections and
1xx that seem to relate to specific aspects of this I-D.

There may very well be implementation legacy issues here that cannot be fixed
just because a new RFC is published that says otherwise. However, I think the
aspect of HTTP version support for CMP needs further discussion so that we
aren't reccommending in 2024 an unmaintained protocol from 1996. For example,
this could be achieved by a reframing why versions matter to CMP. As far as I
understand, the usage of HTTP is pretty basic and any version that supports
HTTP semantics is fine. So what is the motivation to even state any version
requirements?

2. Failure to align to modern HTTP documents

Related to issue 1 but slightly different. This document is obsoleting two
documents but hasn't spent the required effort to align to the most-recent
definitions and terminology of HTTP. Since the primary focus of the document is
HTTP for CMP, I don't think its acceptable to publish a new Standards Track
document that doesn't align strongly.

Specifically, it seems that wherever RFC 6712 referred to HTTP/1.1,
draft-ietf-lamps-rfc6712bis-07 has just swapped it to point to RFC 9112. This
is not sufficient. The most recent family of HTTP documents defines common HTTP
semantics in  RFC 9110. draft-ietf-lamps-rfc6712bis document should be
referring to RFC 9110 where relevant, and ensuring the terminology is
consistent.

For example, draft-ietf-lamps-rfc6712bis-07 uses the term "entity-body" that is
not defined in either RFC 9110 or RFC 9112. Furthermore, to accomodate
differences in message framing across HTTP versions, the common term "content"
is defined [1]. This can be addressed by reformulating phrases like "the answer
MUST be an HTTP response with a "201 Created" status code and an empty message
body." to "the answer MUST be an HTTP response with a "201 Created" status code
and empty content".

The HTTP WG maintains a style guide at
https://httpwg.org/admin/editors/style-guide that can help ensure consistency
of terms.

3. Section 3.8 HTTP considerations

Similar to issue 2, the text here is taken directly from RFC 6712. In the
modern context of HTTP, this text seems strange:

> While all defined features of the HTTP protocol are available to
   implementations, they SHOULD keep the protocol utilization as simple
   as possible.  For example, there is no benefit in using chunked
   Transfer-Encoding, as the length of an ASN.1 sequence is known when
   starting to send it.

The motivation for this SHOULD is not clear. Perhaps the RFC is not the best
place for exploring the entire motivation space. However, I don't understand
why CMP requires any special constraints here compared to any other usage of
HTTP. Furthermore, the example doesn't make much sense in a world where we have
3 major versions of HTTP, where 2 of them effectively have chunked messages by
default. Are we really suggesting CMP shouldn't use more advanced protocols?
That seems nebulous.

WRT Expect header:

>  There is no need for the clients to send an "Expect" request-header
   field with the "100-continue" expectation and wait for a "100
   Continue" status as described in Section 8.2.3 of [RFC2616].  The CMP
   payload sent by a client is relatively small, so having extra
   messages exchanged is inefficient, as the server will only seldom
   reject a message without evaluating the body.

This just seems to be duplicating the observations made in RFC 9110 about usage
of Expect [2] [3]. It also adds some conflicts with the current MUST
requirement to use HTTP/1.0 because 1xx responses were not defined in that
version [4]

4. SHOULD requirement on content-length

This is the major design addition. However, it feels like it is defining the
existing requirement in RFC 9110 Section 8.6 [5] - "A user agent SHOULD send
Content-Length in a request when the method defines a meaning for enclosed
content and it is not sending Transfer-Encoding."  More worringly, the text in
draft-ietf-lamps-rfc6712bis is defined in isolation and lacks context - a naive
implementation that always adds Content-Length but inadvertently
Transfer-Encoding chunked will violate HTTP rules. Furthermore the text states
" giving the length of the ASN.1-encoded PKIMessage" but this might find
friction with HTTP content coding etc.

Its not clear to me why it was decided the SHOULD requirement on content-length
needs explicit pointing out. Presumably it helps the protocol in some way. A
better way to present it would be to defer to the HTTP specifications so no
unintentional problems are introduced. This could be presented as instructions
on how the user agent constructs the CMP request with a highlight of use of
Content-Length in accordance with RFC 9110.

5. Use of encrypted transports

This isn't strictly an HTTP matter but I noticed in my review. RFC 6712 states

> Compliant implementations MUST support TLS with the option to authenticate
both server and client.

draft-ietf-lamps-rfc6712bis contains no similar text, and does not list this in
the changes made by RFC 9480 or this document. Where did it go?

Minor issues:

1. Integrity protection

There is a slightly false statement in Section 5:

> Without being encapsulated in effective security protocols, such as Transport
Layer Security (TLS) [RFC5246] or [RFC8446], there is no integrity protection
at the HTTP protocol level. Therefore, information from the HTTP protocol
should not be used to change state of the transaction.

While the core protocol doesn't provide integrity or authenticity of HTTP
messages, there are are extensions that can provide it, such as HTTP digests
(RFC 9530) with optional HTTP signatures (RFC 9421).

That said, it seems that the recommendation is that even when CMP was used over
TLS, implementations should not trust any HTTP message metadata. Is that right?
If so, consider maybe rephrasing this consideration for clarity e.g.

  "The CMP transaction should not consider any information from the HTTP
  protocol level, regardless of whether any mechanism was used to ensure the
  authenticy or integrity of HTTP messages (e.g. TLS or HTTP digests)"

[1] - https://www.rfc-editor.org/rfc/rfc9110.html#content
[2] - https://www.rfc-editor.org/rfc/rfc9110.html#name-expect
[3] - https://www.rfc-editor.org/rfc/rfc9110.html#section-15.2.1
[4] - https://www.rfc-editor.org/rfc/rfc9110.html#section-15.2
[5] - https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length

Received on Saturday, 26 October 2024 22:54:23 UTC