Subject: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Mar 2018 08:22:03 -0400 (EDT)

We have just submitted a draft aimed at increasing the security of the DNSSEC
with respect to the power that parental zones have over their children.

The aim of this draft is twofold:

1) Allow zones to publicly commit to being delegation_only zones.

The aim here is to counter the argument that the root key and TLD
keys are all powerful and under government control, and can therefor
never be trusted.

2) Allow the creation of DNSSEC transparency logs

With delegation_only zones, we can limit DNSSEC transparency to only
log DS and DNSKEY and their proof of non-existenc. While this does not
prevent all rogue parental data, it does prevent it for those records
that matter (TLSA, SMIMEA, OPENPGPKEY).

Please have mercy on our souls,

Paul, Frank and Wes

A new version of I-D, draft-pwouters-powerbind-00.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Name:		draft-pwouters-powerbind
Revision:	00
Title:		The Delegation_Only DNSKEY flag
Document date:	2018-03-19
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-pwouters-powerbind-00.txt
Status:         https://datatracker.ietf.org/doc/draft-pwouters-powerbind/
Htmlized:       https://tools.ietf.org/html/draft-pwouters-powerbind-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pwouters-powerbind

Abstract:
    This document introduces a new DNSKEY flag called DELEGATION_ONLY
    that indicates that the particular zone will never sign zone data
    across a label.  That is, every dot is considered a zone cut and must
    have its own (signed) delegation.

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: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Mar 2018 16:34:34 +0000

On Mon, Mar 19, 2018 at 08:22:03AM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 57 lines which said:

> We have just submitted a draft aimed at increasing the security of
> the DNSSEC with respect to the power that parental zones have over
> their children.

I'm opposed to this idea.

> While the root and TLD zones are asumed to be almost exclusively
> delegation-only zones,

This is unrelated. You mix two different things, the administrative
issue and the technical one (every subdomain in its own zone). gouv.fr
is administratively a delegation from .fr but is in the same zone.

> the root zone operator (or any level higher in the hierarchy than
> the target victim) could briefly remove the NS and DS records, and
> create a "legitimate" DNS entry for "www.example.org"

That's the DNS. It is a tree. Protecting childs against the parent is
a non-goal, or otherwise we should move to some alternative to DNS
(Namecoin is cool).

> keys are all powerful and under government control, and can therefor

I've read the draft and still can understand nothing in this sentence.

> 2) Allow the creation of DNSSEC transparency logs

May be mentioning draft-zhang-trans-ct-dnssec would be nice?

>  The DELEGATION_ONLY flag has a strong overlap in functionality with
>  the Public Suffix List as both signal a formal split of authority
>  between parent and child.

May be mentioning the defunct DBOUND working group would be a good
idea?

---

From: Bob Harold <[email-masked]>
Date: Mon, 19 Mar 2018 14:12:38 -0400

> > create a "legitimate" DNS entry for "www.example.org"

If the parent simply pointed the NS and DS records to a different version
of the zone, that would accomplish the same effect, even with a
'delegation-only'
flag, so the 'delegation-only' flag really does not solve the problem.

-- 
Bob Harold

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Mar 2018 19:49:45 +0000

On Mon, Mar 19, 2018 at 02:12:38PM -0400, Bob Harold wrote:

> 'delegation-only' flag, so the 'delegation-only' flag really does not solve
> the problem.

The 'delegation-only' flag does not *by itself* prevent parent
domains from answering authoritatively for their child domains,
but it could make "certificate-transparency" more tractable for
DNSSEC.

The idea is to log the DNSKEY RRs observed at each zone apex.
Without the proposed flag, one would also have to log denial of
existence which would make the logs much too large.  CT for DNSSEC
may be impractical anyway, but this flag could make it more realistic.

-- 
	Viktor.

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 19 Mar 2018 16:50:14 -0400

Viktor Dukhovni wrote:
> existence which would make the logs much too large.

Can you expand on what you mean by "much too large"? There are already
existing large scale passive DNS systems that log every RRset that they
observe, and on relatively modest amounts of hardware. Is transparency
for DNSSEC really all that less tractable than the "log every RRset"
problem?

-- 
Robert Edmonds

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Mar 2018 17:34:59 -0400 (EDT)

> for DNSSEC really all that less tractable than the "log every RRset"

Do these large scale passive DNS systems then host the data for (m)any
clients to fully download?

There are also privacy aspects. if you need to audit/log every query,
you are uploading more personal identifiable information. Combined with
TTL=0 or really short RRSIG times, these can become trackers. DNSKEY and
DS records don't come with such short TTLs (or if they would it could
itself be seen as a sign of malicious behavior) so there is much less
of a one to one relationship between those queriers and answers.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Mar 2018 17:53:18 -0400 (EDT)

> I'm opposed to this idea.

Can you clarify whether you oppose to be a user of this new flag, or
whether you oppose of giving others the option of using this flag?

> is administratively a delegation from .fr but is in the same zone.

The idea is that the current technology cannot tell this difference,
but we know at some point down the chain there (usually) is a real owner
change. This allows a zone to publish that information.

One of the side effects is that is there is no zone cut when traversal
a label, that to use this new flag, you have to turn this label change
into a real zone cut. I believe the setup of that is easy and that there
are no real operational impacts caused by this, but I'm happy to hear
from operators, especially TLDs, if there are any concerns with such
a conversion.

> a non-goal

If you can't not trust your friends, who can you not trust? :)

We also did not publish TLSA records in the zone in the old days. Now
we do so there is a clear (new) need to add a bit of protection for the
children against potentially malicious parents. It's completely an
opt-in option for the parent.

Rather then hearing "That's the DNS", I'm more interested in hearing
about whether TLDs would be willing to adopt this solution, and if not,
what actual operational (or organisational?) concerns they would have.

> or otherwise we should move to some alternative to DNS

That is outside the scope of this proposed solution :)

> I've read the draft and still can understand nothing in this sentence.

I'm happy to talk in person this week if that helps. Otherwise if you
have specific questions, I can try to answer them here.

> May be mentioning draft-zhang-trans-ct-dnssec would be nice?

This document is not about ct-dnssec itself. It has as one of its goals,
to make some kind of ct-dnssec possible. But that will be pursued with
another document (and probably on the trans list)

> May be mentioning the defunct DBOUND working group would be a good

What specifically about DBOUND is worth mentioning in the document?

Paul

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 19 Mar 2018 18:24:18 -0400

> clients to fully download?

If those "(m)any clients" were interested in being customers of the
operator of the large scale passive DNS system, then yeah.

https://www.farsightsecurity.com/faq/#q13

> of a one to one relationship between those queriers and answers.

Who is uploading what to whom in this scenario?

Suppose there were something like
https://www.internic.net/domain/root.zone, but instead of being a daily
point in time snapshot of the root zone in master file format, it were a
log that captured each RRset and a publish date, going back for some
small window of time, and it were (ugh) PGP signed so that you know it's
authentic. Would that be enough for independent auditors to construct
and publish their own append-only Merkle tree logs or whatever, so that
folks who want to "trust, but verify" the DNSSEC responses from the root
could do so without having to upload their query logs to anyone? If so,
doesn't this generalize to TLDs as well?

That is, I guess I'm saying if you need cooperation from the zone
publisher anyway, why not just get them to publish what you need, out of
band? (Sure, it doesn't work for the TLDs that don't want to publish
their zones.)

-- 
Robert Edmonds

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Mar 2018 11:26:53 +0000

On Mon, Mar 19, 2018 at 07:49:45PM +0000,
 Viktor Dukhovni <[email-masked]> wrote 
 a message of 30 lines which said:

> domains from answering authoritatively for their child domains, but
> it could make "certificate-transparency" more tractable for DNSSEC.

I don't think that you replied to Bob's remark. He said that the
proposal is useless because it addresses only the case of "answering
authoritatively for their child domain", not the "directing child
domain to someplace".

> existence

There is no denial of existence in the attack explained by Bob.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Mar 2018 07:44:04 -0400 (EDT)

> authoritatively for their child domain", not the "directing child

The goal of the document is to make such malicious changes visible.

If the parent needs to replace NS/DS records, these are easily
auditable identically to Certificate Transparency (rfc 6962bis)
We only need to look (log) the DS/DNSKEY and we do not have
to monitor all TLSA and other security RRtypes. Without this flag,
we need to track and log every DNS RRtype that has public key material
in it.

Paul

---

From: Michael Casadevall <[email-masked]>
Date: Tue, 20 Mar 2018 09:19:06 -0400

> we need to track and log every DNS RRtype that has public key material

Forgive my ignorance on the subject, but I'm having trouble following
how delegation_only flag actually helps in this specific case.

Certificate Transparency works because specifically because the entire
certificate is uploaded, and (assuming a valid cert) a SCT is generated
which can be verified by cross-checking it against the log servers
public key.

Without the RRtypes logged, I'm not seeing how you're supposed to be
able to audit them. In the case where a KSK is compromised, you could
simply sign a new zone record, serve up fraudulent records and remain
unaware. CT as it's implemented in the x509 world (combined with
Expect-CT) specifically prevents unknown but validly signed certificates
from being used.

I'm likely missing something obvious, by only logging DS/NS, it would be
impossible to determine if a private key is misused to serve fraudulent
records which in my mind is a bigger and much more likely/common threat
since one can simply attack a target domain and not try to compromise
the root.

Moving to the topic of the draft itself:

>From a technical point of view, aren't there TLDs that as authoritative
for second level domains as well? The specification likely needs a way
to denote how many levels deep delegation can go. This also would be
true in the case of delegation_only being used at a level above both the
root and TLD zones.

I know historically .name only allowed registration of third-level
domains until 2009, and .uk up until 2014. I'm unsure if any of the TLDs
still restrict and/or is authoritative for second-level domains as well.

At a minimum though, the one case I know off hand of a TLD being
authoritative for a second-level domain is that ICANN requires new gTLDs
are required to publish a wildcard for 90 days when they're added to the
root zone to help catch any name collisions.

Michael

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Mar 2018 09:48:25 -0400 (EDT)

> able to audit them. In the case where a KSK is compromised, you could

Neither this nor certificate transparency protects against a (non-known)
private key compromise. In the case of CA's there are multiple entities
that can create a certificate that need to be audited. In DNSSEC, it is
only the zone or its parents that could create a rogue TLSA record.

> since one can simply attack a target domain and not try to compromise

This is similar to the TLS server private key being compromised without
knowledge. That is not what is being protected.

> true in the case of delegation_only being used at a level above both the

In trying to keep this as simple as possible, the idea was to make this
concept as simple as possible. Making a promise about "every zone cut"
is much easier then making a promise to point to some more complicated
policy that might change over time, and then you have to log/audit the
changes to that policy as well.

For instance, you could have the DNSKEY flag mean "look for the
DELEGATE RRtype policy" and in there specify exceptions for your empty
non-terminals, but it just makes everything much harder.

> still restrict and/or is authoritative for second-level domains as well.

If you run .example and have registrations in *.com.example and
*.edu.example, then the easy way is to create real zones for edu.example
and com.example.

> root zone to help catch any name collisions.

If the software allows signing the wildcard and setting the
delegation-only flag that would mean the wildcard must be
treated as BOGUS, that would not be a problem. It would still
cause problems to be found with name collisions, except now the
name SERVFAILs instead of resolving to 127.0.0.53. Both will show
the name collision as a problem.

Paul

---

From: Michael Casadevall <[email-masked]>
Date: Wed, 21 Mar 2018 03:10:54 -0400

Paul: Thanks for the explanation, it clears up a fair bit for me.
Replies inline.

> only the zone or its parents that could create a rogue TLSA record.

In my mind, the use case I was making was one of that of an intermediate
certificate being misused, but didn't quite make the mental leap to
equating that to the TLD/root zone. In that context, this proposal as
well as logging DS/NS changes makes considerably more sense to me than
it did before.

I still suspect there's value for full logging of all record types, but
that's a separate discussion.

> knowledge. That is not what is being protected.

See above.

> non-terminals, but it just makes everything much harder.

I can appreciate simplicity in a specification. Obviously having a
hypothetical DELEGATE RRtype would considerable more work both in design
and actual implementation/validation. I'm just slightly concerned that
it might make real world deployment more difficult.

My point is here though is it might be a relatively simple extension to
say "I may delegate X levels down" vs. a rather complex system of
delegation/termination for cases where the TLDs disallow second level
registration.

I'm not qualified enough to say definitively if that's actually a
valuable enough case to be worth extending the specification, but I did
want to highlight it for consideration.

> the name collision as a problem.

This likely should be noted as a operational consideration at a minimum
as it impacts how Name Collision tracking is done.

Thanks for your time,
Michael