Subject: [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt

From: Dave Crocker <[email-masked]>
Date: Tue, 2 Apr 2019 17:36:49 -0700

Hi.  Just posted this...

(I'm separately sending this to the dbound list, but figure 
cross-posting isn't productive.)

Comments eagerly sought, of course.

d/

-------- Forwarded Message --------
Subject: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
Date: Tue, 02 Apr 2019 17:23:14 -0700
From: [email-masked]
To: T. Adams <[email-masked]>, D. Crocker <[email-masked]>, 
Dave Crocker <[email-masked]>

A new version of I-D, draft-dcrocker-dns-perimeter-00.txt
has been successfully submitted by D. Crocker and posted to the
IETF repository.

Name:		draft-dcrocker-dns-perimeter
Revision:	00
Title:		DNS Perimeter Overlay
Document date:	2019-04-02
Group:		Individual Submission
Pages:		20
URL: 
https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-dcrocker-dns-perimeter/
Htmlized:       https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-dcrocker-dns-perimeter

Abstract:
    The Domain Name System (DNS) naming syntax provides no meta-data for
    indicating administrative transitions through the hierarchy.  For
    example, it does not distinguish the higher-level portions that
    operate as public registries, versus those that operate as private
    organizations.  This specification creates a basic overlay mechanism
    for defining a logical Perimeter between administrative entities
    through the naming hierarchy.  The mechanism can then be applied for
    a variety of independent administrative indications.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2019 13:58:19 -0400

>Comments eagerly sought, of course.

This seems sorta kinda like my dbound draft, only with _tagged TXT
records rather than a new rrtype, and (unless I missed something) a
hope that somehow you can use a yet to be invented cache to avoid
walking up the tree, where mine used wildcards to do one lookup per
boundary regardless of the tree depth.

I can see that the tradeoffs are different but I don't see why they're better.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 11:22:50 -0700

> boundary regardless of the tree depth.

Section 7's suggestion for using Additional information does not rely on 
caching.

Reliance on existing wildcard depends on propagation of a new RR, which 
continues to be problematic.  There's a reason the Attrleaf table has so 
many entries...

And while there is certainly conceptual overlap with your earlier 
proposal, the current one has differences I'd class as significant.

d/

---

From: "John R Levine" <[email-masked]>
Date: 3 Apr 2019 14:45:01 -0400

On Wed, 3 Apr 2019, Dave Crocker wrote:
> continues to be problematic.  There's a reason the Attrleaf table has so many entries...

Now we're having a discussion about which is the frying pan and which is 
the fire.

In my experience, these days getting a new rrtype that doesn't have extra 
semantics into DNS servers happens pretty quickly.  It's an entry in a 
table or a new short stylized parse/unparse routine.  DNS caches don't 
have to change at all. The problem is the web provisioning crudware, which 
is what I have tried with limited success to address with my DNS extension 
language work.  My dbound draft has no new DNS semantics, just ordinary 
wildcards and an ordinary rrtype.

To put anything into the additional section, you're asking the DNS servers 
to treat a _perim name specially if there are TXT records under the name 
and to go search through the zone to find the extra stuff and put it in 
the additional section.  DNS caches have to change too, to treat the 
additional stuff as non-hostile and pass it through, since caches throw 
away unrecongnized additional sections to prevent cache poisoning (the 
Kashpureff bug.)

You should run this by dnsop where I expect you'll get a great deal of 
pushback and references to the DNS Camel for anything with new semantics.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 11:51:48 -0700

On 4/3/2019 11:45 AM, John R Levine wrote:
> In my experience, these days getting a new rrtype that doesn't have 
> extra semantics into DNS servers happens pretty quickly. 

Now, about /end to end/ support, not just publishing...

Please provide some examples comparable to your proposed use case.  That 
is, what are new RRs that are getting well-scaled, on-going use, defined 
in say the last 5 years?

>   My dbound draft has no new DNS 
> semantics, just ordinary wildcards and an ordinary rrtype.

I noted that.

> To put anything into the additional section, you're asking the DNS 
> servers to treat a _perim name specially if there are TXT records under 

I noted that.

d/

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 3 Apr 2019 11:52:31 -0700

I appreciate the time you invested in this Dave.   I definitely like
that we're thinking in terms of how to leverage DNS and its
distributed model vs emulating the hosts.txt situation, and PSL is
essentially a hosts.txt situation.

Some assert there is a benefit to being able to contain some form of
static list locally for speed.  This happens at the trade-off of
potentially stale data, which we experience as maintainers receiving
energy from expressive TLD admins describing their grief over their
domains being directed at search instead of resolving in DNS because
their pc, tablet or mobile device runs a browser software that did not
contain their TLD.

So in those cases (and potentially others) getting things into DNS
_might_ be better.  I think that a TLD administrator being able to
make direct updates in their own zones is vastly better because it
would both alleviate the arduous process of validating authority of
requests, and streamline the requesting process to near zero on their
updates, and enable more direct and exacting control by the registry
operators.

That said, we fail the community unless the potential replacements
take into consideration the many constituent / subjective uses of PSL
that have evolved across the years before we tick the box next to any
particular solution meeting the diverse needs.

We have to tread carefully here.  I have great respect for the IETF
and the many wise and noble experts that have donated their
experience, time and wisdom towards solutions and standards.  It is a
process that requires patience and I have been told by many in the
developer community that it is not always one that is inclusive or
able to meet the pace of some development cycles and product or
service evolution.

The PSL basically came into existence outside of the IETF process,
borne of real practical needs, and those needs have forked and
matured.

There is a 'lenticular' / perspective issue in how different
stakeholders are using the PSL.   PSL is included in software
libraries, which incorporate it without prescribing how a developer
might use it.  Some care only about the private section of the list,
some only about the "ICANN" section.  Some integrators of the PSL omit
certain elements, or even maintain their own supplementary sections
for their project or service needs.

Think it is safe to assert variety is present - each have an entirely
different need and application of some or all of the PSL's contents
than a browser program, search engine, security professional,
anti-spam, reporting, SSL Cert, or other use.

We (maintainers) don't prescribe specifically how it gets used as
volunteer community maintainers, we just try to guide community
entries and validate them (and focus on ICP-3 or other I* integrity).

PSL is expanding - which grows the file size each time.  As potential
solutions are presented from web developers or even the IETF (or both)
that might help to organize or better architect solutions that could
help PSL from heading towards something that emulates the transition
from the SRI hosts.txt challenges, I fear that unless we can ensure
that some of the dependencies are met by those proposals, the
proposals will not endure, and we'll remain using the PSL in a status
quo manner.

-Jothan
Jothan Frakes

On Wed, Apr 3, 2019 at 10:58 AM John Levine <[email-masked]> wrote:
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 12:02:44 -0700

On 4/3/2019 11:52 AM, Jothan Frakes wrote:
> I fear that unless we can ensure

Jothan,

Thanks for adding comments so quickly after the draft was released.

As the draft notes, it attempts to cover PSL use cases but needs far 
more experienced eyes and minds to find where the PSL emulation needs 
more work.

To that end, anything that documents the dependencies you cite is sure 
to help.

d/

---

From: "John R Levine" <[email-masked]>
Date: 3 Apr 2019 15:06:02 -0400

On Wed, 3 Apr 2019, Dave Crocker wrote:
> Please provide some examples comparable to your proposed use case.  That is, 
> what are new RRs that are getting well-scaled, on-going use, defined in say 
> the last 5 years?

There aren't many other than maybe CDS and CDSKEY.  TLSA was defined in 
2012 and Viktor says it's getting pretty wide use now, particularly 
considering that it needs DNSSEC.

On the other hand, there hasn't been anything with new server semantics 
since NSEC3 in 2008.

This is really an argument for dnsop, not dmarc or dbound.

Regards,

---

From: tjw ietf <[email-masked]>
Date: Wed, 3 Apr 2019 20:19:41 +0100

I was going to say CAA but that’s 6 years old. 

From my high tech gadget

> On Apr 3, 2019, at 20:06, John R Levine <[email-masked]> wrote:
> 
>> Please provide some examples comparable to your proposed use case.  That is, what are new RRs that are getting well-scaled, on-going use, defined in say the last 5 years?
> 
> There aren't many other than maybe CDS and CDSKEY.  TLSA was defined in 2012 and Viktor says it's getting pretty wide use now, particularly considering that it needs DNSSEC.
> 
> On the other hand, there hasn't been anything with new server semantics since NSEC3 in 2008.
> 
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Apr 2019 20:49:12 +0100

Far from widely deployed, but the latest ESNI draft introduced a
new RRTYPE from an experimental range, and it "just worked," which
was a pleasant surprise for me. (And is partly why I am happy to
try that route for RDBD.)

"just worked" here meaning: no registrar web-GUI involved, but
whacking the ascii hex encoding of binary RR values into a zonefile
on a hidden master, having that transferred to the visible NS's and
accessing it from elsewhere using dig with and without DNS/TLS (DoT-
flavoured via stubby) all did really just work. Only hard thing was
finding the docs to say how to refer to the new RRTYPE in zonefile
and dig command line. (I added some notes on that in a readme for my
ESNI code - go to [1] and search down for RRTYPE if you're curious.)

I think that tends to back up John's argument that today, registrar
GUIs are perhaps the main barrier for new RRTYPEs that don't change
the DNS semantically. But there may also be development environment
issues, e.g. I don't know if you can easily query for new RRTYPEs
from e.g. PHP or python code.

Lastly, on Dave's draft itself, I'd be happy if something like that
were deployed, and don't think it overlaps much with or competes
with RDBD. (At least I hope these aren't seen as competing ideas.)

In early chats about RDBD Alex and I did think about the PSL, but we
ended up deliberately not trying to aim for a DNS equivalent. Without
trying to speak for Alex, personally I think emulating the PSL in DNS
is too big a leap to attempt in one step and isn't likely to succeed,
despite it being an outcome that'd be good to (eventually) see.

That's partly how we ended up with (what I'd claim) is the more modest
initial goal of RDBD.

Cheers,
S

[1] https://github.com/sftcd/openssl/tree/master/esnistuff

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 3 Apr 2019 13:19:47 -0700

> ... registrar
> GUIs are perhaps the main barrier for new RRTYPEs ...

s/registrar/DNS Management/

these are often not one in the same - and the only reason I make that
pedantic distinction is that the frequent situation where
DNS Management != registrar
heavily impedes DNSSEC end-to-end configuration, because it needs
config harmony within the registration path (registrar) and the
resolution path (DNS)

Hope that made sense.  Just want to ensure these are not conflated to
avoid drag on efforts

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Apr 2019 21:30:42 +0100

> Hope that made sense.  Just want to ensure these are not conflated to

Fair point.

Ta,
S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 14:07:12 -0700

> I was going to say CAA but that’s 6 years old.

5 was a random number.  I was merely meaning 'recent'.

But suggesting CAA in response to my query means that you think RFC 6844 
has received widespread -- ie, at scale -- end to end adoption and use.

Yes?

Please forgive my skepticism.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 14:09:02 -0700

May we quickly settle on a single mailing list for discussing this draft?

I assume dbound is the right choice but don't really care, as long as it 
is only one.

Absent objection, I propose that this note be the last one cross-posted.

d/