ECH support when curl is using DoH

From: Stephen Farrell <stephen.farrell_at_cs.tcd.ie>
Date: Wed, 13 Sep 2023 02:19:27 +0100

Hiya,

Building on work done earlier by Niall O'Reilly I've recently
updated our curl fork to add support for ECH when curl makes
use of DoH. (I'll send a separate mail asking about ECH when
curl is not using DoH.)

As background, we're working on this as part of the OTF-
funded DEfO project where we've been developing an ECH
implementation using OpenSSL. (See [1] for project details.)
Recently, the IETF TLS working group have (finally:-) decided
to finish up the ECH specification so all going well, there
may be an RFC for ECH early in the new year, with a
subsequent OpenSSL PR for ECH being merged after that. And
then it'll be time to get some ECH support into applications
like curl. Might still all take a while, but the wheels seem
to be turning now;-)

We'd love to get some review as to whether what we've done so
far with our ECH-enabled curl fork looks like a good
direction, when curl is using DoH, and ideally to be told
about things we didn't even think about:-)

There's text describing the state of play in more detail,
including the code changes we've made, at [2]. In case it
helps, the more interesting questions from that are:

- Only the first HTTPS RR value retrieved is actually
processed as described at [2]. That could be extended in
future, though picking the "right" HTTPS RR could be non-
trivial if multiple RRs are published - matching IP address
hints versus A/AAAA values might be a good basis for that.
Last I checked though, browsers supporting ECH didn't handle
multiple HTTPS RRs well, though that needs re-checking as
it's been a while.

- It's unclear how one should handle any IP address hints
found in an HTTPS RR. It may be that a bit of consideration
of how "multi-CDN" deployments might emerge would provide
good answers there, but for now, it's not clear how best curl
might handle those values when present in the DNS.

- The SVCB/HTTPS RR specification supports a new "CNAME at
apex" indirection ("aliasMode") - the current code takes no
account of that at all. One could envisage implementing the
equivalent of following CNAMEs in such cases, but it's not
clear if that'd be a good plan. (As of now, chrome browsers
don't seem to have any support for that "aliasMode" and we've
not checked Firefox for that recently.)

- We have not investigated what related changes or additions
might be needed for applications using libcurl, as opposed to
use of curl as a command line tool.

We'd really appreciate if if someone has the time to give
us feedback on the above, or on any of the additional detail
at [2], especially the code-changes described there.

Thanks in advance,
Stephen.

[1] https://defo.ie
[2]
https://github.com/sftcd/openssl/blob/ECH-draft-13c/esnistuff/building-curl-openssl-with-ech.md

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2023-09-13