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

[Petr Špaček <[e-mail]>]

On 08. 04. 21 16:39, Ben Schwartz wrote:
> 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 
> <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 <[e-mail] 
> <mailto:[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/>
>      > <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
>     <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