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

From: Petr Špaček <[email-masked]>
Date: Thu, 8 Apr 2021 09:54:37 +0200

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

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Apr 2021 10:39:27 -0400

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 <[email-masked]> wrote:

> (
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3
> )
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Petr Špaček <[email-masked]>
Date: Fri, 9 Apr 2021 08:58:55 +0200

On 08. 04. 21 16:39, Ben Schwartz wrote:
> <https://github.com/MikeBishop/dns-alt-svc/pull/313>

Copying the diff here:

> - 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.
> 
> + Recursive resolvers MAY treat the SvcParams portion of the SVCB RR
> + as opaque.  No part of this specification requires recursive resolvers
> + to alter their behavior based on its contents, even if the contents are
> + invalid.

This addresses my concern, thank you!

Petr Špaček

> 
> On Thu, Apr 8, 2021 at 3:55 AM Petr Špaček <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>     <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>>
>      >
>     (https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3
>     <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3>)
>

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 09 Apr 2021 14:07:41 +0200

> This addresses my concern, thank you!

+1, thanks!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/