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

[Peter van Dijk]

On Fri, 2021-04-09 at 08:58 +0200, Petr Špaček wrote:
> 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 
> > 
> 
> 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!

+1, thanks!

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

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 



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 > 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/

 > >
 >
 > 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/ 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/ 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

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/ 



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/ 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/ 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hello WG,

On 3/18/21 9:53 PM, Tim Wicinski wrote:
> 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.

I re-read the draft-03 last week and just had a look at the diff to -04.

There are two things I find unclear about the current draft, and that is
the handling of automatic mandatory keys. Especially the rules on how to
verify the record is consistent (section 7).

The draft mentions

  The SvcParamKey "mandatory" is used to indicate any mandatory keys for
  this RR, in addition to any automatically mandatory keys that are
  present.

and

  This SvcParamKey is always automatically mandatory, and MUST NOT
  appear in its own value-list.  Other automatically mandatory keys
  SHOULD NOT appear in the list either.  (Including them wastes space
  and otherwise has no effect.)

This means an HTTPS record MUST have a port and a no-default-alpn
SVCParam in both the presentation and wire format, without the keys
being present in the mandatory key? It would be good to add an example
or some clarification here.

The second question arises for the "default set" of ALPNs. Section 6.1 says

   Each scheme that uses this SvcParamKey defines a "default set" of
   supported ALPNs, which SHOULD NOT be empty.  To determine the set of
   protocol suites supported by an endpoint (the "SVCB ALPN set"), the
   client adds the default set to the list of "alpn-id"s unless the "no-
   default-alpn" SvcParamKey is present.  The presence of an ALPN
   protocol in the SVCB ALPN set indicates that this service endpoint,
   described by TargetName and the other parameters (e.g. "port") offers
   service with the protocol suite associated with this ALPN protocol.

The HTTPS record mentions that no-default-alpn is automatically
mandatory, but also that alpn has a default value. Which would mean that
that the default alpn is never used?

Or is mandatory a hint to the end-client that it MUST understand the
keys mentioned in order to use the RR? If that is the case, a few words
to that effect would be good.

I hope the rambling above makes the question clear.

Cheers,

Pieter
-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop