Lucas Many thanks for your detailed review. You are absolutely right I am not an HTTP expert. With RFC 9480 we wanted to just add the use of the well-known prefix and path segments. Drafting rfc6712bis was requested by the ADs during IESG review. I see your point that when publishing a rfc6712bis we should also adapt to the changes HTTP got after RFC 6712 was published years ago. Also addressing other comments we received in the past weeks, I also tried to address some of your points. See https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.html and https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-rfc6712bis&url_2=https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.txt. If you see further need for changes and to adopt to current terminology I may need some more guidance. I will be in Dublin from Saturday on. If you are also there, I would be more than happy to discuss the needed changes. Please let me know how I can proceed. Many thanks, Hendrik > -----Ursprüngliche Nachricht----- > Von: Lucas Pardue via Datatracker <noreply@xxxxxxxx> > Gesendet: Sonntag, 27. Oktober 2024 00:54 > An: ietf-http-wg@xxxxxx > Cc: draft-ietf-lamps-rfc6712bis.all@xxxxxxxx; last-call@xxxxxxxx; spasm@xxxxxxxx > Betreff: 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%252 > Fadmin%2Feditors%2Fstyle- > guide&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c52776 > 34666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638655800654363119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C > &sdata=DiL%2BZyUIN2xt5wPBfI8b2eS6jlxrp6Z2fRqblDduXXE%3D&reserved=0 > 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%2Frfc%2Frfc9110.html%23content&data=05%7C02%7Chendrik.brockha > us%40siemens.com%7C5d909c5277634666f7f708dcf6112151%7C38ae3bcd9579 > 4fd4addab42e1495d55a%7C1%7C0%7C638655800654389319%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > CJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NaxwFd5FMjdUjeiWDlUfP5QkLfH > 7O0XLq2y6XptSn14%3D&reserved=0 > [2] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23name- > expect&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c5277 > 634666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0 > %7C638655800654403708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7 > C&sdata=3iyqBguUgZ%2B0hMBJTwogTAITTEphaK%2B1JLuyLq6qR5M%3D&re > served=0 > [3] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23section- > 15.2.1&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c52776 > 34666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638655800654417585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C > &sdata=mRbx6upTGn8Q0P1csUMUdk4oaaGPP%2FdrjJaysPHRVOY%3D&reserv > ed=0 > [4] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23section- > 15.2&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c527763 > 4666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7 > C638655800654431372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C& > sdata=Y2%2BHJsVj4zD%2BPhsfQg6DOlq4tZkmzdJTAQW%2FiStiE1E%3D&rese > rved=0 > [5] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23field.content- > length&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c52776 > 34666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638655800654449812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C > &sdata=CXrLh64UM1sudeu%2BlIQJ3LHnYT3Kt%2BU67EEX7jhEPbQ%3D&reser > ved=0 > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
