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

From: Joe Abley <[email-masked]>
Date: Fri, 12 Feb 2021 11:08:21 -0500

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: [email-masked]
> Subject: New Version Notification for draft-jabley-dnsop-refer-00.txt
> Date: 12 February 2021 at 10:52:38 EST
> To: "Joe Abley" <[email-masked]>
> 
> 
> 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
> 
>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 12 Feb 2021 13:37:57 -0500

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 <[email-masked]> 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: [email-masked]
> *Subject: **New Version Notification for draft-jabley-dnsop-refer-00.txt*
> *Date: *12 February 2021 at 10:52:38 EST
> *To: *"Joe Abley" <[email-masked]>
>
>
> URL:
> https://www.ietf.org/archive/id/draft-jabley-dnsop-refer-00.txt
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 12 Feb 2021 11:37:54 -0800

I like this proposal, look forward to experimenting with this.

I'm not sure about how to defend against downgrade attacks, without
potentially having to touch some other DNSSEC-specific standards. I admit
to not having looked at them again, recently, with this in mind, so the
question I'm asking is something that might have an obvious answer.
In a signed zone (parent) with a zone cut, which includes a REFER record,
with or without the delegation being signed (i.e. with or without a DS
record), what would/could protect against a downgrade?

I think this may need to be analogous to the handling of signed
delegations, if the client (resolver) is DNSSEC-aware, in doing validation.

I think NSEC(3) record(s) proving something would be necessary and
sufficient, to prove the (non-)existence of NS and/or REFER records, and to
include the REFER and RRSIG(REFER) even if RO is not present (possibly
stripped). Synthesis of NS from REFER would probably be analogous to
synthesis of CNAME from DNAME.

I like this a lot, actually. The only question is really uptake by
registries/TLDs and the root.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Feb 2021 15:37:07 -0500 (EST)

On Fri, 12 Feb 2021, Joe Abley wrote:

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

So I think execsum is, REFER is like NS for client, but signed like DS.

What does that buy us. A MITM can't forge the NS to trick a validator
to a dead end (presuming a DS protects them from actual bogus data)

That is the same gain from getting TLS to AUTH servers. But REFER works
without needing transport security.

For everyone else downstream of the validating resolver, they ofcourse
can already be given DS plus child-side (signed) NS records.

And this solution would still be missing a pubkey that can be used
to encrypt the connection to the delegated child zone nameservers.

Seeing how things would likely misimplement REFER, or run into issues
because it gets semi supported through generic records and just flies
along the wrong side of the zone cut, I'd say the dangers of this do
not outweigh the gains.

If we do something drastic like this, at least provide not only the
validatable child NS records, also provide whatever is needed to setup a
fully encrypted connetion to the child's nameserver's so we can get
a fully private query chain with no leaks.

Paul

---

From: Bob Harold <[email-masked]>
Date: Fri, 12 Feb 2021 16:18:59 -0500

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

> I like this.  But don't we also need to sign the glue A and AAAA records
if they are in the child zone?
(I wonder if something like the SVCB record, to include the NS info, plus A
and AAAA, might be better.)

-- 
Bob Harold

---

From: Joe Abley <[email-masked]>
Date: Fri, 12 Feb 2021 17:28:30 -0500

On 12 Feb 2021, at 15:37, Paul Wouters <[email-masked]> wrote:

> What does that buy us.

The draft has a section that describes a couple of other possible advantages, chiefly in avoiding the overloading of a single RRtype which consequently requires special handling downstream of the authority server; the kinds of problems that draft-ietf-dnsop-ns-revalidation hoped to solve, for example.

[...]

> along the wrong side of the zone cut, I'd say the dangers of this do

Just so I understand your reaction, do you mean the dangers *do* outweigh the gains?

> a fully private query chain with no leaks.

I will have to think more about the extent that I think these different solutions overlap.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Feb 2021 17:33:09 -0500

On Feb 12, 2021, at 17:28, Joe Abley <[email-masked]> wrote:
> The draft has a section that describes a couple of other possible advantages, chiefly in avoiding the overloading of a single RRtype which consequently requires special handling downstream of the authority server;

Well, that special handling is there now. So it’s not a big win.

> Just so I understand your reaction, do you mean the dangers *do* outweigh the gains?

No :)

I think for the special processing this introduces, it doesn’t solve enough problems.

> I will have to think more about the extent that I think these different solutions overlap.

And stated by others, signed glue is another issue. Otherwise, those can be used instead of malicious NS records to accomplish the same.

Paul

---

From: Joe Abley <[email-masked]>
Date: Fri, 12 Feb 2021 17:40:14 -0500

> I think for the special processing this introduces, it doesn’t solve enough problems.

Oh, I see what you mean. I was reading dangers vs. gains as risk vs. benefit.

Joe