registration: avoid extra request that ends with HTTP 401

[lidel]

AutoTLS registration API is robust and works fine, but perhaps we could optimize the golden path?

Current flow

• libp2p identify checker at registration.libp2p.direct backend is effectively load-balanced amond multiple nodes, each with own PeerID
• HTTP API atregistration.libp2p.direct/v1/_acme-challenge implements HTTP PeerID Auth from libp2p spec here
• registration requires client to send two requests:
  1. First errors (HTTP 401) and allows client to learn about PeerID from WWW-Authenticate: libp2p-PeerID [...] public-key=... header
  2. Second request uses the PeerID from HTTP 401 response (public-key) and this one is the real one that returns HTTP 200

This means 50% of requests are HTTP 401s (blue in pie chart):

Improvement ideas

(A) "well-known peerid"→ avoid entire request

👉 Are we able to remove the need for first request that always ends with HTTP 401 and cut the number of registration requests by 50%?

My understanding is that the AutoTLS feature does not care about the PeerID of the libp2p.direct backend being globally unique or even being a secret (node does not participate in DHT / swarm, and only performs direct dial to multiaddrs sent to registration API).

👉 👉 Could all backend nodes use the same static PeerID that is generated from the domain (libp2p.direct) as a seed, and make p2p-forge/client attempt registration with that knowledge to avoid 401?

(B) use HEAD → avoid sending body

We could return WWW-Authenticate: libp2p-PeerID public-key=.. in HEAD response, which would save client from signing and sending payload twice + we could filter out HEAD requests and only lok at POST ones.

cc @aschmahmann @MarcoPolo @sukunrt @achingbrain for feedback

[lidel]

Triage Note:

• unlikely to be fixed, this is how libp2p http auth based on peerid works, and Shipyard no longer maintains go-libp2p
• this will go away if clients switch to HTTP-based registration from Add HTTP-only registration via RFC 9421 signatures #82.
• we may decide to park this until that is done, and just close this

[MarcoPolo]

A may be missing context, but the first request is needed for the server to give the client a challenge to sign.

To avoid needing the first round trip for a challenge you could use https://datatracker.ietf.org/doc/html/rfc9729 to get a challenge to sign that is derived from the TLS session (or do something similar yourself if you have access to the TLS session).