Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS

[Ben Schwartz <[e-mail]>]

Thanks for this draft; I think it's clear and could be a helpful
introduction.

>    If the cache has no positive or negative answers for any DNS SVCB
   record for any of a zone's authoritative servers, the resolver needs
   to send queries for the DNS SVCB records for some or all of the
   zone's authoritative servers.

I think it would be worth rephrasing the words "needs to" here.  To me,
this sounds like a normative requirement to perform these queries, but I
suspect that's not what you mean.

>    Because some authoritative servers or middleboxes are misconfigured,
   requests for unknown RRtypes might be ignored by them.  Resolvers
   should be ready to deal with timeouts or other bad responses to their
   SVCB queries.

This sounds a bit pessimistic.  Ralf Weber recently published some figures
showing a ~0.03% failure rate.  For security (in the authenticated case),
any mitigations here are very delicate, and I'm a bit concerned about the
brief treatment here.  (The SVCB draft has an extensive discussion:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1
.)

>    DNS SVCB records act as advisory information for resolvers about the
   encrypted protocols that are supported.  They can be thought of as
   similar to NS records on the parent side of a zone cut: advisory
   enough to act on, but not authoritative.  Given this, authoritative
   servers that know the DNS SCVB records associated with NS records for
   any child zones MAY include those DNS SCVB records in the Additional
   section of responses to queries to a parent authoritative server.

This sounds like a restatement of the definition of "glue".  Can we simply
declare that these records are "glue"?

--Ben

On Sun, May 2, 2021 at 9:55 AM Peter van Dijk <[e-mail]>
wrote:

> Hello DPRIVE!
>
> in the last two draft revisions of our protocol for unauthenticated
> encryption from resolvers to authoritatives, we adopted the SVCB
> discovery mechanism from draft-rescorla-dprive-adox-latest-00. This
> means that the two documents overlap somewhat, and there would be
> effort needed to keep the mechanisms in sync.
>
> To avoid that problem, instead we present here a separate document that
> contains the parts that the two protocols have in common. Our draft is
> adopted; we understand the authors of the authenticated draft intend to
> ask for adoption soon, as well. If the WG adopts this separate
> document, we will not have to keep the discovery bits in sync between
> the two, and we can hammer out the details of discovery once, in a
> single place.
>
> We imagine this would be much more efficient.
>
> - Paul & Peter
>
>
> -------- Forwarded Message --------
> From: [e-mail]
> To: Paul Hoffman <[e-mail]>, Peter van Dijk <
> [e-mail]>
> Subject: [EXT] New Version Notification for draft-pp-dprive-common-
> features-00.txt
> Date: Sun, 02 May 2021 09:51:09 -0700
>
> A new version of I-D, draft-pp-dprive-common-features-00.txt
> has been successfully submitted by Peter van Dijk and posted to the
> IETF repository.
>
> Name:           draft-pp-dprive-common-features
> Revision:       00
> Title:          Common Features for Encrypted Recursive to Authoritative
> DNS
> Document date:  2021-05-02
> Group:          Individual Submission
> Pages:          7
> URL:
> https://www.ietf.org/archive/id/draft-pp-dprive-common-features-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pp-dprive-common-features
> Htmlized:
> https://tools.ietf.org/html/draft-pp-dprive-common-features-00
>
>
> Abstract:
>    Encryption between recursive and authoritative DNS servers is
>    currently being defined in two modes: unauthenticated and fully-
>    authenticated.  These two modes have some features in common, and
>    this document defines those common features so that the documents
>    defining the modes do not need to point to each other.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>