Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson <[e-mail]>]

On Thu, Aug 25, 2022 at 7:58 AM Paul Hoffman <[e-mail]> wrote:

> On Aug 24, 2022, at 7:14 PM, Brian Dickson <[e-mail]>
> wrote:
>
> >> Are you saying that it was explicit after WG Last Call but changed? Or
> during IETF Last Call and was changed?
> >>
> > No, I'm saying that, as far as I can tell, the flow was never explicit,
> and that's a big part of the problem.
> >
> > And I'm saying that if it had been explicit, the concerns would have
> been raised at that time, rather than now.
>
> This WG has dealt with that exact issue many times with well-debated -bis
> documents.
>
> When Warren started this thread, he said "this is *not*  an opportunity to
> re-litigate existing  decisions, make non-required changes, etc." AliasMode
> was significantly discussed during the preparation of the document, and it
> appears that you don't like the conclusion. That's fine, but that's not a
> reason to change this document: it is a reason to create either a document
> that clarifies or updates it.
>
>
Warren also stated "I'd like to also thank the authors and WG in advance
for their time and for keeping this discussion focused".  I interpret that
as, "let's discuss the technical content of the draft."

To that end:
The issue I raised was with the process flow for the client, in section 3,
not the AliasMode section (2.4.2).
In the summary portion of my original email, I put it thusly:

   - Resurrecting ANAME behavior in corner cases is every bit as bad as
   choosing ANAME as the standard.

I.e. I am saying that, under certain conditions (either DNS resolution
problems, or HTTPS connection problems, after successfully resolving a
single AliasMode HTTPS record, and if there exists apex A/AAAA records
[0]), that the prescribed behavior reverts to that of ANAME.
My assertion is that the ANAME behavior is "OMG! That clearly doesn't
work". [1]

My question to anyone responding who disagrees with this assessment is:
Which is it?

   - Is the behavior (in the corner cases) not ANAME-like (requiring that
   apex A/AAAA records have the same values as would be resolved when
   following the HTTPS Alias)?
   - Or, "No, it always works" (even in those corner cases)?
   - Or, "The corner case ANAME behavior exists, but is not a big enough
   deal to make changes before publication."

*Having the opinion that "The corner case ANAME behavior exists, but is not
a big enough deal to make changes before publication", is a valid position.*
I would prefer that this *exact* language be used, if this is the position
being taken by anyone, please.
(E.g. Paul H, is this an accurate characterization of your position?)

BTW: the fall-back corner case is only indirectly related to AliasMode, and
is not related to any of the discussions on AliasMode that occurred, to the
best of my knowledge.
(I'd be happy to be corrected with any single pointer to an on-list thread,
if I'm wrong).

I am not proposing changes to AliasMode itself, nor do I have problems with
the current state of 2.4.2 (other than ambiguous language.)

The problematic bit from 2.4.2 was specifically:

   - The conflation is between "legacy clients", and "preferable for
   clients implementing the specification".
   - Legacy support is not "fallback", which is where the conflation is
   introduced.
   - If non-legacy fallback is a required element to advance the draft,
   let's update the draft accordingly
      - Including establishing a new owner label prefix for fallback
      records, distinct from legacy records, which by definition CANNOT have a
      different name than the origin (apex) name.
      - The conflation is IMHO browsers attempting to infer the intent of
      zone owners, rather than having zone owners explicitly publish
appropriate
      records to that effect (fallback target addresses).

Note also that 2.4.2 only defines AliasMode (what it is, how it is meant to
be used, rules about what the publisher should put in AliasMode records,
and the paragraph about "legacy clients" is not part of, nor is it
subsequently either incorporated by reference, restated, or directly
included in section 3 on Client behavior. (The only other place "legacy" is
referenced is in Appendix C, comparing the draft to the ANAME and HTTP
proposals that predate this draft.)

NB: Viktor Dukhovni had a laser-focused contribution to the discussion (on
Wed, Aug 24, 1:58 PM), which I believe does a much better job of
articulating the issue than my original message did. (Thanks, Viktor).
I would strongly suggest reading his message and replying/commenting there.

Brian

[0] Apex A/AAAA records may exist for purposes other than publishing the
site whose delegation is performed via HTTPS record, including SMTP or
other non-web services, or for providing legacy clients with instructions
on obtaining HTTPS-aware clients.
[1] See the extensive WG ANAME discussions for why ANAME doesn't work
for everyone. AliasMode *does* work for everyone. Resurrecting the
ANAME behavior alongside AliasMode, is snatching defeat from the jaws of
victory.