Maarten, I provide my additional responses below prefixed with "JG2-".
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 3/10/26, 3:06 PM, "Maarten Wullink" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Jim, JG-This is the purpose of draft-ietf-regext-epp-https in defining a standard mechanism for the stateful EPP to ride on top of HTTP, which must leverage the HTTP-layer session semantics. Let us know whether you see any technical issues in draft-ietf-regext-epp-https. MW: I understand the intent, but leveraging HTTP-layer sessions introduces a second, overlapping session layer. This changes the semantics from a simple transport to a protocol layer that now influences session behavior JG2-Use of HTTP sessions makes for a stateful HTTP connection to a server, which is really not an overlap with the EPP session layer, but a building block for defining a statement EPP connection on HTTP. JG-Correct, the EoH connection leverages the HTTP session to match what exists today with the TCP connection in RFC 5734. Establishing the EoH session is based on successfully executing the EPP <login> command, as is the case for EoT. MW: yes, the problem is that the lifecycles of the HTTP and EPP sessions must be kept in sync JG2-The EPP session is dependent on the stateful connection, so if the stateful HTTP connection fails so does the EPP session. This is the same case as for a TCP connection. Is your concern related to the speed by which the client will recognize that the EPP session has been terminated, which can take more time than a TCP connection, but the client will be able to identify that the HTTP session is no longer active. Do you see any gaps in draft-ietf-regext-epp-https to help clarify this? JG-I don't see the complexity here since the HTTP-layer is handling the establishment of an encrypted stateful connection to the server via the HTTP session. The EPP application protocol is not impacted by the underlying transport layer, which I've demonstrated in the Verisign EPP SDK by running all the EPP tests via configuration of the transports (EoT, EoH, and EoQ). MW: reading the draft it is very clear that the use of HTTP does leak into EPP semantics, HTTP sessions and EPP sessions MUST be linked and the server MUST track the state of the EPP session and licecycle changes need to be reflected in HTTP session also. e.g. logout in EPP would also require HTTP session. to be terminated. JG2-Of course all of the EPP commands and responses for an individual EoQ connection need to ride on the same HTTP session. I don't see this as an issue, where I've implemented a multi-session pool for EoH, like EoT, where its simple for the client to borrow a EoQ connection, send a command, process the response, and return the EoQ connection back to the pool. The multi-session pool also automatically established the EPP session by submitting the EPP <login> command prior to adding it to the pool. There is no difference with EoT and the HTTP transport protocol is encapsulated fully. JG-There is the concept of an idle timeout in implements of EoT, which applies to EoH as well to keep the connection (EoT or EoH) alive. The EoH connection pool in the Verisign EPP SDK transparently handles the keep-alive via the EPP <hello> and handles closing and refreshing the EoH connections. MW: this is more of a hack to overcome architectural problems with these sessions. JG2-This is existing behavior for servers that do implement an idle timeout. The requirement for an idle timeout is independent of the underlying transport, where the server can automatically terminate the EoT connection or EoH connection if there has been no commands received within the idle timeout. JG-I'm not sure what pressure you're referring to. If EoH becomes an RFC there will be a standard approach defined for implementing EPP over HTTPS. There have been numerous implementations of EPP over HTTPS using different approach that would be consolidated down to one approach as an option of registries to deploy if desired. MW: my concern is that when we have EoH with very basic HTTP support, then implementors will probably also would like to use more advanced features, for example URL routing. JG2-Please review draft-ietf-regext-epp-https and provide feedback on normative language that can help address your concern. We cannot help implementers from going beyond what's defined in the RFC, but we can include normative language to help define the guardrails. JG-There needs to be no impact to the EPP semantics in defining an EPP transport. If there are required changes to EPP semantics, then I don't believe the considerations in Section 2.1 of RFC 5730 would be met. MW: i think there might be a problem with http/2/3 where multiplexing may be default in client http libs, the server MUST check for out of order request? JG2-The built in pooling / multiplexing in HTTP/2 and HTTP3 is what led to not supporting pipelining in EoH. There is no way to control order if a client is pipelining on top of HTTP/2 or HTTP3. JG-Please review draft-ietf-regext-epp-https and identify any concrete issues of the HTTP usage that poses a risk that we can directly address. MW: see my review below. JG-RPP represents the cleanest approach for the use of HTTP, since it will be stateless, but EPP should have the option of use of a more modern transport to what exists today with EoT. MW: i agree, but we have to think more about what potential impact it will have on future EPP developents JG2-I'm not clear on what future EPP develops you're referring to. Providing additional transport options for EPP is a net positive that registries can choose if it meets the needs of their customers. I would be cautious about using DNS as an example for "modernizing" EPP. DNS is fundamentally a stateless protocol and therefore maps much more naturally onto HTTP-based transports. JG-DoH was brought up since it matches the intent in defining an HTTP transport for an existing application protocol. DoH requires the server to support both the GET and POST HTTP methods for passing the encoded DNS query packets and returning the DNS query responses. HTTP is used as a pure transport with DoH and with EoH. MW: yes, but the upper layer protocol (DNS) is a fundamentally different protocol, and due to its stateless nature more suitable for running over HTTP, you cannot use DoH as argument for EoH. JG2-DoH was simply brought up to point to another example of an existing application protocol that has defined an HTTP transport, which is not REST and is out-of-scope for BCP 56. JG-What aspect would not be consistent? If an implementer has the intent to implement a new HTTP transport protocol for EPP or customize EoH, then they would not be implementing EoH as defined by the working group. Is there any normative language that you see needs to be added to draft-ietf-regext-epp-https to ensure consistency in the future? MW: see my review below JG2-Great, I'll reply to your detailed comments in a follow-up response. I really appreciate you taking the time to perform the review. MW: review comments: - 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. "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. "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 "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. "MUST include ""no-cache" in the "Cache-Control" header and include "0" in the "Expires" header to disable caching." it woule be better to say that standard HTTP mechanisms MUST be used to ensure caching is disabled. This would be more future proof "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. "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. "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. "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 "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. 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. " 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? "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 ... "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 "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? "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. "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? "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? "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? 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)) 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. "Servers are REQUIRED to support TLS 1.2 [RFC8446][RFC9155] or higher" Why not require TLS 1.3 as minimum? "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? "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? "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 abnd if not if you can use any CA, then what is the added value? "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 wich makes loadbalancing less effective. _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
