Maarten, Thank you so much for your detailed review and feedback of draft-ietf-regext-epp-https. I respond to your review feedback embedded below, prefixed with "JG-". The co-editors will need to discuss the actions from your feedback.
Thanks, -- JG James Gould Fellow Engineer [email protected] <mailto:[email protected]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] <mailto:[email protected]>> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> <http://verisigninc.com/>> - Review comments 3. Session Management "An EPP server implementing this specification MUST listen for HTTP session requests on a standard HTTP port assigned by IANA" I don't like the MUST for HTTP port, should be able to use other port also. and if you want to specify port then use HTTPS port. JG-Agreed, HTTP should be replaced with HTTPS, as in "An EPP server implementing this specification MUST listen for HTTPS session requests on a standard HTTPS port assigned by IANA". "Such a session is initiated by the client via sending a GET request to the sever." A HTTP session MUST be linked to an EPP session, therefore the session should only be created, and cookie set after successful login command. Cannot have a HTTP session without linked EPP session. JG-Incorrect, the HTTP session is strictly used to maintain a statement EoQ connection and is not associated with the authentication a successful login command." Would it help for us to the commonly used terms like what was done in the Introduction of draft-ietf-regext-epp-quic, which would include EoH, EoH connection, and EoQ session. It’s the EoQ session that maps to a successfully established EPP session. The EoQ connection is associated with a successfully established EPP connection, which is realized by establishing the statement HTTP session in the HTTP GET. "The GET request MUST include "application/epp+xml" Does not say what the server should do/return when incorrect media type is used by client JG-Good point, I believe the incorrect media type is provided. The appropriate behavior of the server is to return the HTTP 415 "Unsupported Media Type" error response. Do you agree? "The server MUST include the EPP Greeting in the response." The server MUST return the greeting after receiving request without a session included, this should normally be the first request, but this is not made clear. JG-See my response about the HTTP session above. The HTTP session is not mapped to the EPP session, but to the EPP connection. The GET response must include the EPP greeting to comply with the EPP server state machine, defined in section 2 of RFC 5730. "MUST include ""no-cache" in the "Cache-Control" header and include "0" in the "Expires" header to disable caching." it would be better to say that standard HTTP mechanisms MUST be used to ensure caching is disabled. This would be more future proof JG-Thank you for that future proofing suggestion. "The server MUST use the "Set-Cookie" header to include a token that represents the identifier of the HTTP session" Set-Cookie MUST only be set after EPP session has been created. JG-Incorrect, see my responses to the lack of mapping the HTTP session to the EPP connection instead of the EPP session. Inclusion of the terms I believe would be helpful. "The HTTP session represents an EPP connection, referred to as an EPP over HTTP (EoH) connection, which is initiated by the initial GET request." Create HTTP session only after successful login command. JG-No, the HTTP session is associated with the EPP connection and not the EPP session. "The EPP session begins with a successful EPP <login> command on the EoH connection and can be referred to as an EPP over HTTP (EoH) session." Both HTTP and EPP session MUST be created after successful login command. JG-No, the HTTP session only ensures having a stateful EoQ connection. "An EPP session is normally ended by the client issuing an EPP <logout> command." this assume there will always be clean logout, better would be to assume the client never sends logout command. Here is disconnect between HTTP and EPP sesion l JG-There is no assumption of a clean logout, but that is considered the recommended or normal method. The unclean termination is covered in the following sentence. "A server MAY also end an EPP session that has been either active or inactve for longer than a server-defined period" this is a workaround because of the architectural mismatch between HTTP and EPP session. JG-EPP already has a mismatching between the EPP connection and the EPP session. A client can establish an EPP connection and simply send an EPP <hello> without ever submitting the EPP <login>. That's sort of pointless but demonstrates the separation of the EPP connection and the EPP session. Once the EPP session is established, the termination of the EPP session via the EPP <logout> command will terminate both the EPP session and the EPP connection. The use of inactive timeouts (idle timeout) is common practice for EPP to deal with stale EPP connections / sessions established by the client. There is really no difference between EoH and EoT in this case. 4. Message Exchange "With the exception of the EPP Greeting, EPP messages are initiated by the EPP client in the form of EPP commands." Maybe better to use the term EPP transaction" here and not EPP messages? you cannot initiate a message. JG- This sentence was reused from EoT, but I agree that its somewhat confusing and we can look to revise it. The issue is that there is a hierarchy in EPP, where an EPP message is at the highest level of abstraction with implementations of the EPP message by the EPP response, the EPP command, the EPP greeting, and the EPP hello. This would be better stated as "With the exception of the EPP greeting, EPP messages are returned to the EPP client based on the EPP client sending an EPP message." The reason that the EPP command is not used here is that the EPP hello "message" can be sent to receive the EPP greeting message. We're really correcting the language used in EoT, but I agree that it needs to be revised. " An EPP server MUST return an EPP response to an EPP command in the HTTP response to the respective HTTP request." I had to read this sentence 3 times to understand it, maybe rewrite to: An EPP server MUST return the EPP response within the HTTP response for a request? JG-I believe the intent here is that there is a mapping of the EPP command with the HTTP request and the associated EPP response with the HTTP response. The EPP commands are processed in order, which means for EoH, every EPP command is embedded in the HTTP request and the EPP response is embedded in the associated HTTP response. How about " An EPP server MUST embed the EPP response in the associated HTTP response to the HTTP request containing the EPP command."? "The EPP command and the EPP response MUST include "application/epp+xml" in the "Content-Type" header with the character encoding of the EPP XML" The HTTP request and response MUST include ... JG-This would be best to reference the HTTP request and HTTP response, as in "The HTTP request and the HTTP response MUST include "application/epp+xml" in the "Content-Type" header with the character encoding of the EPP XML". The EPP command and the EPP response is contained in the HTTP request and the HTTP response, where the HTTP headers are associated with the transport messages. "The EPP command and the EPP response MUST include "application/epp+xml" in the "Content-Type" header with the character encoding of the EPP XML (e.g., "application/epp+xml;charset=UTF-8"). The EPP response MUST include "no-cache" in the "Cache-Control" header and include "0" in the "Expires" header to disable caching." duplicate text, this is also in session section, maybe add separate section(s) for this JG-Agreed, I believe we can remove this and go with your more forward-looking language. "HTTP does not guarantee that POST requests are idempotent. However, the semantics of EPP do require EPP commands to be idempotent, so processing a command more than once will produce the same net effect on the repository as successfully processing the command once" This is puzzling to me, text states HTTP does not guarantee and semantics of EPP do require EPP commands to be idempotent. I think this text can be rewritten to make clear that EPP guarantees idempotency? JG-Yes, that's what its saying. Even if HTTP POST does not guarantee idempotency, the design of the EPP application protocol does. "Commands MUST be processed independently and in the same order as received from the client." Client is maybe not the correct term here, a client can start multiple active HTTP sessions. command order should be enforced at the session level not client level. JG-We could change this to read "Command MUST be processed independently and in the same order as received on the EoH connection." Does that help? "Servers MUST return an EPP 2002 response (i.e. Command use error) if the client issues an EPP command with either an empty or an invalid HTTP session identifier." Only for HTTP POST requests is probaly meant here? JG-In thinking about this more, I believe if the server receives an EPP command via the HTTP POST without the required HTTP session identifier, the command MUST NOT be processed, and the HTTP 400 "Bad Request" is returned. This is a failure at the transport layer and not the application layer. Do you agree? "A server SHOULD impose a limit on the amount of time required for a client to issue a well-formed EPP command. A server SHOULD end an EPP session if a well-formed command is not received within the time limit" maybe add new section about server best practices? JG-This is reused from EoT, since implementing an idle timeout applies to EoH as well. We would need to consider the best practices from our lessons from EoT that would apply to EoH (and EoQ) and any specific best practices specific to each transport. "EoH clients MUST wait for a server response to a command before sending a subsequent command." This assumes client use HTTP2/3 library where this is configurable. Maybe add text that the server MUST return an specific error when out or order commands are received? JG-The server won't know whether the commands are received out of order, since there is no sequence. The only answer to supporting the order of commands is to disallow pipelining by the client. The server may not even know whether the client is pipelining, since it would need the ability to look ahead. The ordering of the commands and the lack of pipelining is a responsibility of the client, which is why the normative MUST is used here. 6.1. EPP Extension Registry "The EPP transport described in this document should be registered by IANA in the Extensions for the Extensible Provisioning Protocol" A new EPP transport is not an EPP extension, it is clearly described differently in RFC5730 and is never event mentioned in RFC3735 (Guidelines for Extending the Extensible Provisioning Protocol (EPP)) JG-I believe the EPP transport is a form of extensibility, which in my mind is an extension defined within RFC 5730. I don't believe my interpretation will pass consensus, so we may go with Pawel's proposal of creating an EPP transports IANA registry. Do you agree with Pawel's proposal? 8. Security Considerations "Since client credentials are included in the EPP <login> command, HTTPS (Section 4.2.2 of [RFC9110]) MUST be used to protect them from disclosure while in transit" All HTTP request and responses MUST be protected, not only the login request, text should be changed to reflect this. JG-Agreed, we'll look to clarify this. "Servers are REQUIRED to support TLS 1.2 [RFC8446][RFC9155] or higher" Why not require TLS 1.3 as minimum? JG-TLS 1.2 is still deployed widely in the industry, but I agree we should recommend the use of TLS 1.3. How about something like "Servers are RECOMMENDED to support TLS 1.3 [RFC8446] or higher and MUST support TLS 1.2 [RFC5246] or higher"? "HTTP session identifiers SHOULD be randomly generated to mitigate the risk of obtaining a valid one through a brute-force search." Server can also limit the number of allowed GET request within a period of time? JG-This would be another server policy, which equates to the EoQ connection limit. This could be handled on a per web server basis, a per client basis, and an overall EoQ connection limit. This could be handled in a best practices or server considerations section. "Servers MAY limit the lifetime of active sessions to avoid them being exchanged for a long time." MAY should probably be a SHOULD or a MUST? JG-I agree that you want to define a upper session limit. I could go with the MUST. "As a further measure to enforce the security, servers MUST require clients to present a digital certificate. Clients who possess and present a valid X.509 digital certificate, issued by a recognized Certification Authority (CA)" Why a MUST for client certificates, and who issues the certificate, is it the registrar and if not if you can use any CA, then what is the added value? JG-Yes, this needs to be modified, since draft-albanna-regext-eku-mtls-in-epp provides additional options related to the client certificates (e.g., registry issued certificates, self-signed certificates). We'll look at this and make an adjustment. "If the EPP server is configured as a load balancer routing the requests to a pool of backend servers, some of the aforementioned checks SHOULD be implemented on the load balancer side" How do you handle dead EPP sessions, e.g. when server where EPP state was kept was restarted or due some other unknown reason, the state is no longer available. client may endup on server where the HTTP session is linked to a dead EPP connection? what error is returned, here HTTP and EPP codes may need mapping. without a shared storage for sessions, (shared db somewhere) the server must use sticky sessions which makes load balancing less effective. JG-I'm not crazy about the language of that sentence in the draft. The HTTP gateway would need to support sticky HTTP session, which would not be visible to the load balancer. If the client passes an invalid HTTP session id, then the HTTP gateway should fail the request. The dead EoQ connections would be cleared in the application server due to the timeouts, and the HTTP gateway should fail the request to a cleared HTTP session. I don't recommend adding the complexity of shared storage for the sessions, since the clients can easily establish new sessions. _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> To unsubscribe send an email to [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
