Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: are ALPN values desirable command line options?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 23 Oct 2023 09:44:02 +0200
> Am 22.10.2023 um 01:47 schrieb Stephen Farrell via curl-library <curl-library_at_lists.haxx.se>:
>
>
> 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.
For this to work, curl needs to know the ALPN protocol. Because otherwise, it does not know how to talk to the server or understand the answer. If one would specify "--alpn xyz" what should curl do when "xyz" as negotiated?
We could support things like "--alpn h3,http/1.1,h2" and do the connection negotiation accordingly. That would then work similarly to "--http1.1", "--http2" etc. But outside of that, I fail to see a way to support other ALPN values.
Cheers,
Stefan
>
> 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>--
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Mon, 23 Oct 2023 09:44:02 +0200
> Am 22.10.2023 um 01:47 schrieb Stephen Farrell via curl-library <curl-library_at_lists.haxx.se>:
>
>
> 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.
For this to work, curl needs to know the ALPN protocol. Because otherwise, it does not know how to talk to the server or understand the answer. If one would specify "--alpn xyz" what should curl do when "xyz" as negotiated?
We could support things like "--alpn h3,http/1.1,h2" and do the connection negotiation accordingly. That would then work similarly to "--http1.1", "--http2" etc. But outside of that, I fail to see a way to support other ALPN values.
Cheers,
Stefan
>
> 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>--
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-10-23