On Wed, Aug 24, 2022 at 4:11 PM Eric Orth <ericorth=
40google....@dmarc.ietf.org> wrote:
>
>
> On Wed, Aug 24, 2022 at 4:58 PM Viktor Dukhovni <ietf-d...@dukhovni.org>
> wrote:
>
>> * When the initial SVCB (also HTTPS, ...) query returns an AliasMode
>> result, lookup failures in all subsequent SVCB/HTTPS queries are
>> "fatal"
>> even for SVCB-optional clients.
>>
>> This more closely approximates predictable client behaviour that doesn't
>> randomly ignore redirection records on unexpected transient "lookup
>> failures" (see above vs. "lookup success").
>>
>> Of course if even the initial lookup fails, the client may well be using
>> unsecured UDP behind a broken CPE (that mangles queries for unfamiliar
>> record types), and may have no ability to resolve any SVCB or HTTPS
>> records, and have no access to DoH or DoT. In that case it seems
>> somewhat reasonable for SVCB-optional to fall back to status quo ante.
>>
>
> Regarless, once AliasMode records are found, these MUST be used and
>> partial lookup failure along a non-empty (so far) alias chain needs
>> to be fatal.
>
>
> This would be a big non-editorial change from the current draft, and I
> don't see any need for such a rule rising to the "exceptional
> circumstances" bar at this stage.
>
"at this stage" is only the case due to the draft not being explicit in the
flow. It would definitely have been addressed sooner if the draft had been
more explicit in specifying this behavior.
I.e. "at this stage" is not a show-stopper, as Warren has already
explained. If you want to discuss the timing, that is a separate
conversation to have with the AD.
Yes, this is a non-editorial change. If it were limited to an editorial
change, it could be handled with an Errata or via a -bis document.
> Why would such behavior be necessary beyond a vague desire to be more
> consistent with the behavior of CNAMEs?
>
(See below, as well as Viktor's response.)
>
> As a client implementor, I think the draft already has the correct
> behavior here, and I do not support making changes at this time.
>
The current discussion is about whether the draft's behavior is correct, as
well as whether the draft's language is unambiguous (i.e. all implementers
interpret it the same way):
- If the determination is that the behavior is correct, then NBD, no
changes needed (i.e. a moot point).
- If the determination is that the behavior is incorrect, I don't
understand why you would oppose making changes.
> I don't like when implementing new specs makes my client more susceptible
> to errors in cases where a non-implememnting client would have kept working
> fine (except for cases of obvious domain misconfiguration or where breaking
> is important for security). If a client receives non-aliased A and AAAA
> records that a non-HTTPS-implementing client would have been able to use
> successfully, why should an HTTPS-aware client be forced to ignore them and
> refuse to load a website?
>
Consider the following, non-hypothetical set-up (i.e. one that is actually
being planned to be used, modulo the issue under discussion here):
- HTTPS record with Target of some CDN object
- A/AAAA records with addresses returning a web page that is NOT the
same as the page served via the CDN
- E.g. a web page that says "Your web browser is unsupported, please
upgrade to one of the following browsers to access the page in
question." ,
including provisioning of the web page with the correct TLS
certificate for
the domain in question.
- Legacy clients would be being given instructions on how do update
their clients
- The instructions MIGHT be links to knowledge base articles
published and maintained by the client vendors
- The instructions MIGHT be different on the basis of things like
User-Agent strings and geographic profiles (including language and/or
distinct URIs)
- Both HTTPS and A/AAAA records have extremely long TTLs, anywhere
from 1 hour to 2 days. If the client ends up using these, they get the
"Your web browser" message for that long
- The HTTPS target may have a very short TTL on its records (60 seconds
is one very common one).
- Do the math: if you roll the dice every 60 seconds, and after the dice
turning up a bad result, you then get the "Your web browser" for 2 days.
What is the relationship between the error probability, and the resulting
expected proportion of traffic going to the "Your web browser" page?
- Also consider different browser implementations, where one
implementation honored the AliasMode (without going back to the A/AAAA),
and the other did the other thing (going back to the A/AAAA)
- The former implementation would present clients with either
temporary failures (and presumably re-attempted connections), or
permanent
failures (because the authority configuration was broken). Clients would
never see the "Your web browser" message.
- The latter would sometimes show the user the message to pick a
different browser, as the browser they were using was identified as a
legacy client (even if that identification was erroneous).
If your desire is to have the client have a fallback A/AAAA record set to
use, the draft SHOULD be updated to specify a different set of records than
the one used for the legacy clients.
You could, for example, update the specification for the fallback to use
something like "_HTTPS_fallback.$ORIGIN" as the owner name. Legacy clients
would not know about that, but non-legacy (HTTPS-aware) clients would know
about it, and only if the records existed AND a failure occurred, would
those alternate addresses be used.
DNS zones that did not want to support the fallback mechanism would not
publish those records; DNS zones that did want that would publish them.
Those records could even be CNAME records from _HTTPS_fallback.$ORIGIN to
$ORIGIN.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
