Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Ben Schwartz <[e-mail]>]

This is a fun proposal, Joe.  (I think it should probably also go to
DPRIVE, although it's mostly the same folks.)

Regarding the Security Considerations, I would suggest that REFER-aware
recursive resolvers (1) should also implement QNAME minimization, and (2)
should send a REFER query in parallel with any shortened-QNAME query.  It
seems to me that should be roughly sufficient to prevent the downgrade
attack (if the parent is signed) without adding latency.

On Fri, Feb 12, 2021 at 11:08 AM Joe Abley <[e-mail]> wrote:

> Hi all,
>
> I have discovered that without liberal access to bars and hallways at
> in-person IETF meetings, I no longer know how to tell the difference
> between ambition and insanity when it comes to technical proposals. I am
> quite prepared to find out that in this case the needle is at the crazy end
> of the scale.
>
> Happy Friday!
>
>
> Joe
>
> Begin forwarded message:
>
> *From: *[e-mail]
> *Subject: **New Version Notification for draft-jabley-dnsop-refer-00.txt*
> *Date: *12 February 2021 at 10:52:38 EST
> *To: *"Joe Abley" <[e-mail]>
>
>
> A new version of I-D, draft-jabley-dnsop-refer-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
>
> Name: draft-jabley-dnsop-refer
> Revision: 00
> Title: REFER: A New Referral Mechanism for the DNS
> Document date: 2021-02-12
> Group: Individual Submission
> Pages: 14
> URL:
> https://www.ietf.org/archive/id/draft-jabley-dnsop-refer-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-jabley-dnsop-refer/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer
> Htmlized:       https://tools.ietf.org/html/draft-jabley-dnsop-refer-00
>
>
> Abstract:
>   The Domain Name System (DNS) incorporates a namespace that is
>   comprised, in practice, of multiple so-called zones.  Each zone is,
>   in principal, a finite tree structure which can be administered
>   autonomously, and is connected to exactly one parent zone and zero or
>   more child zones.  These connection points are known as zone cuts; a
>   parent zone contains information that allows the servers responsible
>   for the child zone to be found.
>
>   The current DNS specification encodes that information about child
>   zones using an "NS" resource record set in the parent zone, and a
>   corresponding "NS" resource record set in the child zone.  These two
>   resource record sets have identical owner names, class, and resource
>   record type but can differ in other respects such as the time-to-live
>   (TTL) attribute, the resource record data associated with each set
>   and the availability of cryptographic signatures.  This property of
>   being similar, related but potentially different has led to
>   operational complexity.
>
>   This document proposes a change to how zone cuts are encoded in the
>   parent zone, allowing the resource records in the parent and the
>   child zone to be more clearly distinguished and protected separately
>   using cryptographic signatures.
>
>   It is not at all clear that this is a good idea.  To restate in
>   stronger terms, the goal of the experiment described in this document
>   is to determine just how bad an idea this is.
>
>
>
>
> 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
>
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>