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.
are ALPN values desirable command line options?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stephen Farrell <stephen.farrell_at_cs.tcd.ie>
Date: Sun, 22 Oct 2023 00:47:03 +0100
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
Received on 2023-10-22
Date: Sun, 22 Oct 2023 00:47:03 +0100
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
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature