<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">Please read on for comment in context below, both from<br>
my experience as one of the team for the <a href="https://defo.ie/" title="Developing ECH for OpenSSL (DEfO)" style="color: #3983C4;">DEfO</a> Project,<br>
and from personal reflection based on this experience.</p>
<p dir="auto">On 25 Dec 2024, at 19:10, Jan Schaumann via bind-users wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Well, "support" here means different things, though.<br>
In my experimentation, I've found that some browsers<br>
only support some features of the HTTPS records.</p>
<p dir="auto">See e.g.:</p>
<p dir="auto"><a href="https://issues.chromium.org/issues/40937306" style="color: #777777;">https://issues.chromium.org/issues/40937306</a><br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1869075" style="color: #777777;">https://bugzilla.mozilla.org/show_bug.cgi?id=1869075</a></p>
<p dir="auto">AFAIU, Chrome is primarily (only? at this time?)<br>
interested in using HTTPS records for ECH, which last<br>
I checked (about 6 months ago or so), Safari at least<br>
didn't support.</p>
</blockquote>
<p dir="auto">This doesn't surprise me. People working to develop an<br>
ecosystem for ECH have seen a need for client-side support<br>
for the HTTPS RR as indispensable, both in browsers and<br>
in other clients, and have focused their efforts on what<br>
would be most productive for them.</p>
<p dir="auto">I'm not currently aware of the browser-developers' plans.<br>
OTOH, Stephen Farrell and I have contributed ECH-only<br>
HTTPS RR code to <strong>curl</strong> and <strong>libcurl</strong>.</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Honoring of alpn, port, and the behavior of handling<br>
chains in alias mode, or how to behave if an alias<br>
doesn't have A/AAAA records etc. all is also still<br>
very much hit or miss, I've found.</p>
</blockquote>
<p dir="auto">I've thought about how to extend what we've done in DEfO<br>
in the "obvious" directions: to service-parameters other<br>
than ECHConfigList, to DNS transports other than DOH,<br>
to alias-chasing, and to resolution of target addresses.</p>
<p dir="auto">I have prototype code for both alias-chasing and for making<br>
use of the address hints in <strong>libcurl</strong>, but doing the job<br>
properly is a bigger project than is possible with the<br>
resources currently available.</p>
<p dir="auto">Besides, I believe that alias-chasing and resolution of<br>
target addresses both belong in the resolver, rather than<br>
in application-library code. This is why I have opened<br>
issues, seeking to have this addressed, with both<br>
<a href="https://gitlab.isc.org/isc-projects/bind9/-/issues/4810" style="color: #3983C4;">ISC</a> and <a href="https://github.com/NLnetLabs/unbound/issues/1065" style="color: #3983C4;">NLnet Labs</a>. I am sure<br>
that these will receive attention as resources allow.</p>
<p dir="auto">On 26 Dec 2024, at 21:56, Peter 'PMc' Much wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">In practice, on my Berkeley/FreeBSD machines,<br>
getaddrinfo provides the results of that selection. getaddrinfo<br>
may or may not ask DNS in the process, depending on nsswitch.conf.</p>
<p dir="auto">Then, as far as I understand the HTTPS RR, it is designed to<br>
short-circuit this procedure and have the application client<br>
directly query the HTTPS RR, in order to benefit by faster startup,<br>
and probably ignoring any preference settings from ip6addrctl.<br>
I don't yet know how this will work out in practice,</p>
</blockquote>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">but it seems<br>
to me there is some potential for unexpected behaviour.</p>
</blockquote>
<p dir="auto">I think this last observation is an understatement. 8-)</p>
<p dir="auto">However, as I read <a href="https://www.rfc-editor.org/rfc/rfc9460" title="Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records),
Nov. 2023" style="color: #3983C4;">RFC9460</a>, the section which specifies the<br>
<a href="https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv6hint" title="RFC9460: specification of address hints" style="color: #3983C4;">address hints</a> seems to recommend <strong>NOT</strong> short-circuiting<br>
traditional address resolution, but rather using the address data<br>
announced in A and/or AAAA RRs, if possible.</p>
<p dir="auto">A discussion on how to limit (or prevent) the "potential for<br>
unexpected behaviour" seems beyond the scope of this mailing<br>
list, and will likely be informed by the <a href="https://datatracker.ietf.org/doc/html/draft-pauly-v6ops-happy-eyeballs-v3-02" title="Happy Eyeballs Version 3: Better Connectivity Using Concurrency" style="color: #3983C4;">Happy Eyeballs v3</a><br>
draft, and by RFCs including <a href="https://www.rfc-editor.org/rfc/rfc3493" title="Basic Socket Interface Extensions for IPv6, Feb. 2003" style="color: #3983C4;">RFC3493</a> and <a href="https://www.rfc-editor.org/rfc/rfc6724" title="Default Address Selection for Internet Protocol Version 6 (IPv6),
Sep. 2012, obsoletes RFC3484, has errata" style="color: #3983C4;">RFC6724</a>, as well<br>
as <a href="https://www.rfc-editor.org/rfc/rfc9460" title="Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records),
Nov. 2023" style="color: #3983C4;">RFC9460</a>.</p>
<p dir="auto">Happy New Year!<br>
Niall O'Reilly</p>
<hr style="border: 0; height: 1px; background: #333; background-image: linear-gradient(to right, #ccc, #333, #ccc);">
</div>
</div>
</body>
</html>