Hiya,
This is a little long-winded before I get to the question. Sorry about that;-) One of the things we'd like to see for ECH is that "smaller" web sites and hosters can relatively easily make use of ECH. Part of making that easier is helping with ways to publish new HTTPS RRs that contain ECHConfigList values for such deployments. One way to do that is via a spec we're working on in the IETF. [1] That spec calls on the entity with write-access to the DNS (the "zonefactory" aka ZF in [1]) to check whether or not ECH works with a web site before publishing the new HTTPS RR value with a new ECH public key/ECHConfigList. (Making that check is a reason we want to provide a curl command line option that takes the base64-encoded ECHConfigList value as a command line argument. That's the ``--ech ecl:<base64>`` variant implemented in [2].) Now, just like a web site can ask the ZF to publish a new ECH public value/ECHConfigList, the HTTPS RR the web site wants to see published can also contain an ALPN value that clients ought later use when connecting to the site. So, finally getting to the question, for a ZF to use curl to check if a requested ALPN works or not, (in conjunction with the relevant ECHConfigList), there'd have to be a new way to pass in ALPN values from the command line. As of now, IIUC there's no way to do that, but should there be? If the answer's "yes," then we can play about with doing that as part of our ECH PR. [2] That could later be separated out into a different PR I guess if that's better. If the answer's "no," I'd love to understand why it's a bad plan for curl to accept a command line argument for setting ALPN values. Thanks, S. [1] https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech [2] https://github.com/sftcd/curl/tree/ECH-experimental
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
