Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https

[Ben Schwartz <[e-mail]>]

Thanks for the feedback, Petr.  I think the easiest solution is to relax
the requirement language.  I've proposed a change here:
https://github.com/MikeBishop/dns-alt-svc/pull/313

On Thu, Apr 8, 2021 at 3:55 AM Petr Špaček <[e-mail]> wrote:

> On 18. 03. 21 21:53, Tim Wicinski wrote:
> >
> > This starts a Working Group Last Call for draft-ietf-dnsop-svcb-https
> >
> > Current versions of the draft is available here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
> > <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>
> >
> > The Current Intended Status of this document is: Proposed Standard
> >
> > Please review the draft and offer relevant comments.
> > If this does not seem appropriate please speak out.
> > If someone feels the document is *not* ready for publication, please
> > speak out with your reasons.
> >
> > This starts a two week Working Group Last Call process, and ends on:  2
> > April 2021
>
> I realize I'm already late, but I think this is worth raising with the WG:
>
> Version -04 contains this:
>
> 4.3.  General requirements
>
>     Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR
>     as opaque and SHOULD NOT try to alter their behavior based on its
>     contents.
>     When responding to a query that includes the DNSSEC OK bit
>     ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers
>     MUST accompany each RRSet in the Additional section with the same
>     DNSSEC-related records that they would send when providing that RRSet
>     as an Answer (e.g.  RRSIG, NSEC, NSEC3).
>
>
> The catch is that this "SHOULD NOT ... alter behavior" goes against RPZ
> and any other filtering technique employed by the resolver.
>
> As a specific example, operators are already asking resolver vendors to
> treat ipv4hint and ipv6hint the same way as A/AAAA for purposes of the
> "Response IP Address" Trigger in the context of RPZ filters.
> (
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3
> )
>
> Does WG want to say anything in the HTTPS draft or leave it to the
> imagination of vendors?
>
> In my eyes, 4.3 "SHOULD NOT ... alter behavior" is unnecessary for
> interoperability, so I think clarification is needed to make it clear
> that local policy on resolver overrides "SHOULD NOT alter" instruction
> in section 4.3. General requirements _if_ resolver operator deems
> necessary.
>
>
> Let me be clear:
> It would not be very reasonable to believe that HTTPS RR will be in
> practice allowed to work as a loophole to A/AAAA filtering on resolvers,
> so the question is if WG prefers to have it mentioned in the RFC text or
> not.
>
> --
> Petr Špaček
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>