Last Call Review of draft-ietf-lamps-rfc6712bis-07
review-ietf-lamps-rfc6712bis-07-httpdir-lc-pardue-2024-10-26-00
Request | Review of | draft-ietf-lamps-rfc6712bis |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | HTTP Directorate (httpdir) | |
Deadline | 2024-10-23 | |
Requested | 2024-10-09 | |
Authors | Hendrik Brockhaus , David von Oheimb , Mike Ounsworth , John Gray | |
I-D last updated | 2024-10-26 | |
Completed reviews |
Tsvart Last Call review of -07
by Lars Eggert
(diff)
Genart Last Call review of -07 by Meral Shirazipour (diff) Secdir Last Call review of -07 by Charlie Kaufman (diff) Artart Last Call review of -07 by Claudio Allocchio (diff) Opsdir Last Call review of -07 by Mohamed Boucadair (diff) Httpdir Last Call review of -07 by Lucas Pardue (diff) |
|
Assignment | Reviewer | Lucas Pardue |
State | Completed | |
Request | Last Call review on draft-ietf-lamps-rfc6712bis by HTTP Directorate Assigned | |
Reviewed revision | 07 (document currently at 09) | |
Result | Not ready | |
Completed | 2024-10-26 |
review-ietf-lamps-rfc6712bis-07-httpdir-lc-pardue-2024-10-26-00
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