Subject: [dbound] New version of draft-deccio-dbound-organizational-domain-policy

From: Casey Deccio <[email-masked]>
Date: Wed, 11 Nov 2015 16:36:51 -0500

I've made modifications to
draft-deccio-dbound-organizational-domain-policy, captured in a -01 draft.

Changes include the following:
- Add BNF representation of ODUP statements
- Updates to algorithm for completeness
- Rewording of and examples added to textual algorithm
- Add notion of "fetch" directive (documentation to come)
- Add resolution examples

Your reviews are appreciated.

Cheers,
Casey

A new version of I-D,
> draft-deccio-dbound-organizational-domain-policy-01.txt
> has been successfully submitted by Casey Deccio and posted to the
> IETF repository.
>
> Name:        draft-deccio-dbound-organizational-domain-policy
> Revision:    01
> Title:        Organizational Domains and Use Policies for Domain Names
> Document date:    2015-11-11
> Group:        Individual Submission
> Pages:        23
> URL:
> https://www.ietf.org/internet-drafts/draft-deccio-dbound-organizational-domain-policy-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/
> Htmlized:
> https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-deccio-dbound-organizational-domain-policy-01
>
> Abstract:
>   Various Internet protocols and applications require some mechanism
>   for identifying policy surrounding the use Domain Name System (DNS)
>   names.  In this document we describe an extensible system in which
>   domain name policies can be discovered at various levels in the DNS
>   tree.
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Nov 2015 20:52:51 -0500

Hi all--

>> has been successfully submitted by Casey Deccio and posted to the

I've done a quick read of this draft, and i'm sorry to say that i was
unable to attend the dbound meeting in yokohama.  I still don't fully
understand the tradeoffs involved here, but i thought maybe exposing my
ignorance publicly would be useful :) Sorry if these questions/concerns
have been brought up already, please point me to pre-existing answers!

 0) if i understand it correctly, the use of the _odup zone itself for
    the "negative policy realm" seems likely to violate the DNS privacy
    intent of
    https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/,
    since the existing queries might have to make it all the way back to
    the root nameservers (or whoever is operating _odup).  Am i
    misunderstanding this?  It seems to be mentioned in Security
    Considerations, but it's not clear to me why we need to accept this
    additional privacy cost.  Are the only additional advantages the
    zone prefetching/caching/SOA freshness checks? if so, surely we can
    come up with other solutions besides that?

 1) I thought that the hijacking of TXT records in the way SPF did it
    was frowned upon by the DNS community.  The SPF research has a page
    and a half of text about why the TXT record ended up winning for
    them and the dedicated RRTYPE lost, but it seems like a cautionary
    tale rather than something to emulate:

        https://tools.ietf.org/html/rfc6686#appendix-A

    Shouldn't this use a dedicated RRTYPE from the start instead of a
    custom (and therefore otherwise-globally-forbidden) label and a TXT
    record?  Implementors can use the "private use" range initially for
    experimentation and request an early assignment if we think this is
    the way to go:

      https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

 2) For this to be used in an endpoint, the endpoint will need the
    results of the full list of queries, right?  this differs from qname
    minimization, where the recursive resolver can do the chain of
    more-subtle queries and simply return the correct answer.  For
    endpoints that want to validate DNSSEC-signed odup queries, they'll
    have N responses that they need to validate, each with potentially N
    signatures forming the full chain for each.  is this the O(N^2) that
    came up in the meeting?

 3) section 5 says "Directives other than "bound" and "-all" MUST NOT be
    used in the policy-negative realm.", but the examples in section 5.1
    have an "org" directive (mapping from the !www.ck PSL entry).  I
    understand that as a PSL exception, !www.ck may not technically be
    in the "policy-negative realm", but that means that the later
    conflation (e.g. in section 5.2) of "policy-negative realm" with
    "_odup DNS zone" aren't quite correct either.  There may be only
    terminology fixes needed here, but i don't understand the scheme
    well enough to be sure.

 4) step 4 in section 4 needs an s/ODUUP/ODUP/

hope this is useful feeback,

     --dkg

---

From: Casey Deccio <[email-masked]>
Date: Wed, 11 Nov 2015 22:06:18 -0500

Hi Daniel,

On Wed, Nov 11, 2015 at 8:52 PM, Daniel Kahn Gillmor <[email-masked]>
wrote:

> I've done a quick read of this draft,

Thanks!

>     misunderstanding this?

That is correct.  But...

>   It seems to be mentioned in Security
>     additional privacy cost.

also in the security section:

  "Additionally, referencing a
   locally downloaded version of the policy-negative realm for partial
   or "sufficient" ODUP resolution, as suggested in Section 5 can reduce
   queries to the _odup zone."

Section 5 says:

  "It also enables consumer applications to work offline by simply
   downloading all the policy-negative statements when those are
   sufficient for the purposes of the application.

   "Even when a self-contained listing of the policy-negative names is
   locally available but insufficient for the needs of the consumer
   application (i.e., a more specific assurance of policy is necessary),
   this resource can provide an efficient starting place for ODUP
   resolution.  Rather than starting with the root domain name as the
   organizational domain, the shortest organizational domain below the
   policy-negative boundary is used first.  This increases efficiency by
   avoiding network latency associated with unnecessary DNS lookups."

In addition to increasing efficiency by avoiding costly DNS lookups, what
is lacking is an explicit statement of privacy, although it is mentioned in
the security section (quoted above).  Local download of the policy-negative
zone would be the preferred method for ODUP resolution.  Anticipated
high-traffic zones could also make their realms available (e.g., using the
"fetch" directive--which admittedly isn't fleshed out).

For example, the following are the queries and responses for www.example.com
:

com._odup./TXT: NOERROR: v=odup1 +bound
example.com._odup./TXT: NXDOMAIN
www._odup.example.com./TXT: NXDOMAIN
With a locally downloaded policy-neative realm, the lookups change to
only the following:

www._odup.example.com./TXT: NXDOMAIN

Only _odup.example.com sees the queries.

Also, it's entirely possible (and encouraged?) that over time the
policy-negative realm would shrink, since the capability to declare these
items in arbitrary namespace through policy delegation would be possible.

>   Are the only additional advantages the

No, the primary benefit is a backwards compatible solution with a
facilitated transition path.  The zone prefetching/caching are means to
enable the local download, which results in the increased efficiency
(through decreased latency) and privacy.

> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

I'm not married to TXT, but it's certainly the path of least resistance for
a solution like this.  And SPF isn't alone here: don't forget DKIM and
DMARC, the latter of which was approved earlier this year.  There could be
discussion on this, but the precedent is there.

>     results of the full list of queries, right?

I suppose it depends on the endpoint--how the application is consuming the
data.

As currently constituted, the output of ODUP resolution for a given name is:

- organizational domain (above which is the organizational "boundary")
- policy domain (the same as, or a subdomain of the organizational domain;
where the actual use policy is)
- policy (the policy--either explicit, or inherited from the policy domain)

>   this differs from qname
>     more-subtle queries and simply return the correct answer.

Yes, it is slightly different.

> For
    came up in the meeting?

No.  The O(N^2) that was mentioned in the meeting was due to a
misunderstanding about how the resolution worked, specifically with regard
to how the labels are arranged around the _odup label in the resolution
process.

DNSSEC validation requires extra queries for DNSKEY and DS records, but
remember we're working within the same namespace as the names we're looking
up.  So there aren't any extra queries.

>     terminology fixes needed here, but i don't understand the scheme

You are correct.  I forgot to add that "+org" is also allowed.

>  4) step 4 in section 4 needs an s/ODUUP/ODUP/

Will fix it.

> hope this is useful feeback,

Yes.  Thanks!

Casey

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Nov 2015 22:53:16 -0800

On Wed, Nov 11, 2015 at 7:06 PM, Casey Deccio <[email-masked]> wrote:

> I'm not married to TXT, but it's certainly the path of least resistance
> for a solution like this.  And SPF isn't alone here: don't forget DKIM and

The general tension here -- and I'm sure I'm over-simplifying it somewhat
-- is that the DNS community absolutely insists that the right thing to do
is a new RRTYPE, while operators absolutely insist that that's not
pragmatic because nearly all DNS provisioning systems short of editing your
own zone files don't include easy support for new RRTYPEs.  There are also
other operational concerns.

We summarized these issues in the SPFBIS working group here:
http://tools.ietf.org/html/rfc6686#appendix-A

If we try to push a DBOUND solution that involves further overloading of
TXT, we should probably expect to have that battle again.

-MSK

---

From: Casey Deccio <[email-masked]>
Date: Thu, 12 Nov 2015 08:51:53 -0500

> up.  So there aren't any extra queries.

Minor update: if the _odup subdomain space (at any level, not just the root
level) is delegated (i.e., in the form of a DNS delegation, with NS
records), then, if signed, there would be additional queries for DNSKEY and
DS for that zone.  However, the worst case (but highly unlikely) number of
"extra" queries is 2n, which is O(n), not O(n^2).

Casey

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2015 17:08:51 -0000

>other operational concerns.

SPF has the unusual problem of using TXT records at unprefixed names, which
means they are in the same RRSET with TXT records that are used for other stuff.

We got a lot less hate for DKIM since those TXT records are at names
with _domainkey prefixes.

My thing would work either way, although it seems somewhat cleaner with
its own RRTYPE.

R's,
John