Lucas Thank you for your review and your comments. Probably this email overlaps with my interim status from Thursday. Please see my responses to your comments inline below. The latest version of the draft ready for submission and a diff to the latest version on datatracker are available on github: - https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc6712bis.html - 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 Please let me know if the proposed changes sufficiently address your comments. Hendrik > Von: Lucas Pardue via Datatracker <noreply@xxxxxxxx> > Gesendet: Sonntag, 27. Oktober 2024 00:54 > > 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? [HB] We removed the requirement to support HTTP/1.0 OLD Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support HTTP/1.1 [RFC9112]. NEW This draft requires uses of the POST method (Section 3.3) and the "Content- Type" header field (Section 3.4) which are available since HTTP/1.0 [RFC1945]. This specification also specifies use of persistent connections (Section 3.2). This document refers to HTTP/1.1 as specified in [RFC9110] and [RFC9112] for further details. > > 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%7C5d909c5277634 > 666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6 > 38655800654363119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata= > DiL%2BZyUIN2xt5wPBfI8b2eS6jlxrp6Z2fRqblDduXXE%3D&reserved=0 that can > help ensure consistency of terms. [HB] Thank you for pointing me at the style guide. I implemented some changes and hope it reads better now :-) If there is further improvement required, I appreciate any further guidance. > > 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] [HB] Thank you for pointing this out. We dropped the complete Section 3.8. > > 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. [HB] Thank you for pointing us at this. We dropped the paragraph on the "Content-Length". > > 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? [HB] This change came in with -07. You are right, I should have mentioned it in the change history. We removed the sentence because TLS is not strictly required to protect the CMP transactions as explained in that paragraph. We also wanted to align with the spirit expressed in RFC 9482, CoAP transfer for CMP. To further improve this security consideration, I propose the following change. OLD 5. CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential technical or business critical information. Therefore, users of the HTTP transfer for CMP messages might want to consider using HTTP over TLS according to [RFC9110] or virtual private networks created, for example, by utilizing Internet Protocol Security according to [RFC4301]. NEW 5. CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential personal, technical, or business critical information. The protection of the confidentiality of CMP messages together with an initial authentication of the RA/CA before the first CMP message is transmitted ensures the privacy of the EE requesting certificates. Therefore, users of the HTTP transfer for CMP messages should consider using HTTP over TLS according to [RFC9110] or using virtual private networks created, for example, by utilizing Internet Protocol Security according to [RFC7296]. I also added a note to the end Section 3.6. NEW Note that https can also be used instead of http, see item 5 in the Security Considerations (Section 5). > > 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)" [HB] We updated this Security Consideration as follows: OLD 2. 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. NEW 2. Without being encapsulated in effective security protocols, such as Transport Layer Security (TLS) [RFC5246] or [RFC8446], or without using HTTP digest [RFC9530] 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, regardless of whether any mechanism was used to ensure the authenticity 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%7C38ae3bcd95794f > d4addab42e1495d55a%7C1%7C0%7C638655800654389319%7CUnknown%7CTW > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C0%7C%7C%7C&sdata=NaxwFd5FMjdUjeiWDlUfP5QkLfH7O0XLq2y > 6XptSn14%3D&reserved=0 > [2] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23name- > expect&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c527763 > 4666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C > 638655800654403708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata > =3iyqBguUgZ%2B0hMBJTwogTAITTEphaK%2B1JLuyLq6qR5M%3D&reserved=0 > [3] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23section- > 15.2.1&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c527763 > 4666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C > 638655800654417585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata > =mRbx6upTGn8Q0P1csUMUdk4oaaGPP%2FdrjJaysPHRVOY%3D&reserved=0 > [4] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23section- > 15.2&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c52776346 > 66f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8655800654431372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Y > 2%2BHJsVj4zD%2BPhsfQg6DOlq4tZkmzdJTAQW%2FiStiE1E%3D&reserved=0 > [5] - https://www.rfc-/ > editor.org%2Frfc%2Frfc9110.html%23field.content- > length&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C5d909c527763 > 4666f7f708dcf6112151%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C > 638655800654449812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata > =CXrLh64UM1sudeu%2BlIQJ3LHnYT3Kt%2BU67EEX7jhEPbQ%3D&reserved=0 > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
