Subject: [Trans] 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: 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