On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: > > > Relatedly, the results presented by EKR [1] at the most recent DNSOP > > meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS > > records through their local resolver. To me, this implies that > functional > > origin endpoints are likely to be required even if client software gains > > SVCB/HTTPS support. > > This is why my suggested client behaviour was cognisant of this impediment. > > - If the client's *initial* SVCB lookup succeeds, *then* fallback is > no longer an option. > > - If initial SVCB resolution fails (SERVFAIL, timeout, ...) > then the client behaves as though the SVCB record does not exist. > > This results in more predictable behaviour, without optimising for > failure. I don't think "more predictable" is really a desirable or achievable outcome in this case. Sophisticated clients (e.g. web browsers for HTTP, iterative resolvers for DNS) tend to develop highly tuned heuristics and state machines in pursuit of performance and reliability within their particular constraints. I think an instruction not to fall back in this case would likely be ignored. It also strikes me as questionable from a standards perspective: if SVCB itself is optional, surely the client always has the right to change its mind and disable its support for SVCB? > If the origin zone directs the service elsewhere, and there > are no last-mile DNS lookup roadblocks, then the protocol becomes > "reliable" (optimises for success and predictability, over fallback > recovery leading to potentially/eventually undesirable outcomes). > > > > I believe this balance could be revisited in several years' time, if > "HTTPS > > Record" support becomes sufficiently universal. > > Indeed it is a possible position to say that the Internet is not yet > ready for semantically distinct services seen by SVCB-aware and legacy > clients. In addition to the deployment concerns I've mentioned earlier, a deployment of this kind would be intrinsically insecure: a hostile intermediary could override the choice of which semantically distinct service is seen by the client. That's another reason why this configuration is not permitted. But I think that latching on success of the initial lookup > largely addresses the present impediments to reliance on SVCB. > The same could have been said of EDNS0 fallback, but the IETF wisely did not attempt to leap straight to that configuration in the initial RFC. Instead, we gave client implementors plenty of room to tune their own fallback behaviors, and came back to tighten the system up much later when it became safe to do so. > Viktor notes with concern that AliasMode is a "non-deterministic > > redirect". Instead, the draft attempts to model the client behavior as a > > preference ordered stack of endpoints: > > > > I also noted an issue around the initial $QNAME having prefix labels (in > the case of SVCB rather than HTTPS), and so this is likely not the name > you want appended as a fallback to the target list. > Indeed, I think this is a clarity/precision problem that we should correct. Specifically, this "final value of $QNAME" endpoint is only used if it is not the initial value of $QNAME (i.e. if an AliasMode record was found). Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to > preclude publishing A/AAAA records there, making some of the example > configurations in the draft impractical. > I don't agree with this reading of RFC 1123. There is no requirement that address records only be placed on hostnames, and there is no requirement that TargetName be a hostname. If I were making an argument here, it might be about compatibility with RFC 8553 (Attrleaf), but hopefully this is mostly moot per the above.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
