Subject: [DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-ds-remove-00.txt

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 25 Aug 2015 17:55:11 -0400

This is a proposed update the CDS/CDNSKEY processing to address the
omission in RFC7344.

Comment please,

Olafur

Ps: I'm using a new markup tool to write the ID thus any errors in format
are my fault.
https://github.com/miekg/mmark

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Aug 25, 2015 at 5:48 PM
Subject: New Version Notification for draft-ogud-dnsop-ds-remove-00.txt
To: Olafur Gudmundsson <[email-masked]>

A new version of I-D, draft-ogud-dnsop-ds-remove-00.txt
has been successfully submitted by Olafur Gudmundsson and posted to the
IETF repository.

Name:           draft-ogud-dnsop-ds-remove
Revision:       00
Title:          Removing DS records from parent via CDS/CDNSKEY
Document date:  2015-08-25
Group:          Individual Submission
Pages:          5
URL:
https://www.ietf.org/internet-drafts/draft-ogud-dnsop-ds-remove-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ogud-dnsop-ds-remove/
Htmlized:       https://tools.ietf.org/html/draft-ogud-dnsop-ds-remove-00

Abstract:
   RFC7344 specifies how trust can be maintained in-band between parent
   and child.  There are two features missing in that specification:
   initial trust setup and removal of trust anchor.  This document
   addresses the second omission.

   There are many reasons why a domain may want to go unsigned.  Some of
   them are related to DNS operator changes, others are related to
   DNSSEC signing system changes.  The inability to turn off DNSSEC via
   in-band signalling is seen as a liability in some circles.  This
   document addresses the issue in a sane way.

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: Paul Wouters <[email-masked]>
Date: Tue, 25 Aug 2015 18:15:02 -0400 (EDT)

On Tue, 25 Aug 2015, Ólafur Guðmundsson wrote:

> This is a proposed update the CDS/CDNSKEY processing to address the omission in RFC7344. 
> Comment please, 

As you state, it was an omission on purpose. The document wanted to
ensure the security state was never changed from insecure <-> secure.
I believe it is useful to specify a method for those who can or are
willing to use it to do so.

I fear a non-technical discussion to uhm ... flare up :)

For the technical part, if we write a document that states how to go
from secure to insecure, why not just also include in that document
how to go from insecure to secure. These operations are kind of
orthogonal. Plus, we already implemented a prototype on how to do that,
so we can just write that up (minus the TXT records alternative)

I would also add a note that if you lose the private key, this document
does not help you go insecure, as an out-of-band method will have to be
used to signal that.

IANA would also need to update the algo number 0 from "RESERVED" to
something else - eg "NO DIGEST".

Paul

---

From: Shane Kerr <[email-masked]>
Date: Wed, 26 Aug 2015 03:02:01 +0000

Paul,

On Tue, 25 Aug 2015 18:15:02 -0400 (EDT)

> willing to use it to do so.

I agree completely.

Perhaps we can add blinking red letters of warning to the draft for
users? ;)

> I fear a non-technical discussion to uhm ... flare up :)

A well-grounded fear.

> so we can just write that up (minus the TXT records alternative)

AIUI, CDS/CDNSKEY manipulation requires signed records, right? So that
means that the person adding new CDS/CDNSKEY records has the ability to
sign the zone with the private key.

Going from insecure to secure does not have the same property. You can
bootstrap trust, but it is from a different kind of thing. IIRC, Joao
added code to the soon-to-be-expired DLV registry which used a nonce
TXT record to confirm that the person adding to DLV could add TXT
records to the domain. But there are several attacks which could be
made that allow this (not likely, but also not possible). DNSSEC trust
is not the same as "ability to update a zone".

To be clear, I fully support adding such a way to bootstrap DNSSEC
trust, just pointing out that it is not the same as *removing* DNSSEC
trust.

> does not help you go insecure, as an out-of-band method will have to be

True. Seems obvious but probably worth a note. :)

--
Shane

---

From: Bob Harold <[email-masked]>
Date: Wed, 26 Aug 2015 08:45:56 -0400

On Tue, Aug 25, 2015 at 11:02 PM, Shane Kerr <[email-masked]>
wrote:

> It should be obvious to the person reading it, but should we add a
warning, in both the "Abstract" and the "Security considerations" sections,
that this reduces the security of the domain?  Just so no one says we did
not warn them.  I would at least add it to the Security section, just for
completeness.

-- 
Bob Harold

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 26 Aug 2015 14:13:15 -0400

> is not the same as "ability to update a zone".

I think writing a document on acceptable ways to establish trust  a useful
document but that at this point has no protocol implications for
CDS/CDNSKEY that I can see, thus I prefer to not include that in this
simple protocol document.
Establishing the initial trust is one of the goals of the auto-DS work that
some of us are experimenting with.

> Will add a note to that extent basically list cases in where you can not
use this to go unsigned.

> > something else - eg "NO DIGEST".

You are right I need to update the document to reflect the use of 0 as
digest algorithm in DS as the examples stand, not
just the DNSKEY algorithm number.

I guess we could say "CDS 0 0 X" where X is the algorithm in the current DS
record, but that makes limited sense.
Q: is it better to use DNSKEY algorithm 0 as:  DELETE flag in CDS/CDNSKEY
or should we reserve a different Algorithm code that for that?

 Olafur