Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt

From: Bob Harold <[email-masked]>
Date: Thu, 3 Nov 2016 11:59:27 -0400

On Sun, Oct 30, 2016 at 11:49 PM, Matthew Pounsett <[email-masked]>
wrote:

> Hi all.
>
> I've submitted an update for the below draft which I'd like the working
> group to eventually consider for adoption.  If there's time in the agenda,
> I'd like to ask the chairs for some time to discuss this in Seoul.
>
> As with the previous version, I'm looking for some specific feedback on a
> few things.
>
> 1) I believe this draft represents operational experience that could be
> added to RFC6781.  While it doesn't (intentionally) change anything in
> 6781, I think the additional operator change procedure justifies the
> "updates" meta-data in the draft.  With the increase in gTLDs and the
> expected future increase in gTLD transfers I think it's important to put
> this information in front of operators searching for advice, which makes
> having it appear as a link from the 6781 meta-data important.  I'd like to
> get the group's feeling on that.
>
> 2) RFC 6781 does not explicitly describe the timings of each step in the
> operator change procedure, leaving that as an exercise for the reader to
> obtain by reading earlier sections of the RFC.  The -01 version of this
> draft followed that style for a couple of reasons: first, so as not to
> unnecessarily duplicate any information; second, to avoid unintentionally
> introducing any ambiguity or update to the information in 6781.  I've been
> of two minds on that, however.  I felt that the aim of this draft–to
> provide advice to inexperienced operators–was not well served by leaving a
> prose description of the procedure out.  With the recent publication of
> errata for § 4.1.2, my opinion has tipped slightly the other way, and so
> I've added text to describe the steps and their timings.
>
> 3) I don't believe this draft raises any *new* security considerations, so
> I've done my best to incorporate by reference the security considerations
> from 6781.  I'd like to know your thoughts on this as well.
>
>
> ---------- Forwarded message ----------
> From: <[email-masked]>
> Date: 30 October 2016 at 23:29
> Subject: New Version Notification for draft-pounsett-transferring-
> automated-dnssec-zones-02.txt
> To: Matthew Pounsett <[email-masked]>
>
>
>
> A new version of I-D, draft-pounsett-transferring-au
> tomated-dnssec-zones-02.txt
> has been successfully submitted by Matthew Pounsett and posted to the
> IETF repository.
>
> Name:           draft-pounsett-transferring-automated-dnssec-zones
> Revision:       02
> Title:          Change of Operator Procedures for Automatically Published
> DNSSEC Zones
> Document date:  2016-10-31
> Group:          Individual Submission
> Pages:          7
> URL:            https://www.ietf.org/internet-
> drafts/draft-pounsett-transferring-automated-dnssec-zones-02.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-pounsett-transferring-automated-dnssec-zones/
> Htmlized:       https://tools.ietf.org/html/d
> raft-pounsett-transferring-automated-dnssec-zones-02
> Diff:           https://www.ietf.org/rfcdiff?
> url2=draft-pounsett-transferring-automated-dnssec-zones-02
>
> Abstract:
>    Section 4.3.5.1 of [RFC6781] "DNSSEC Operational Practices, version
>    2" describes a procedure for transitioning a DNSSEC signed zone from
>    one (cooperative) operator to another.  The procedure works well in
>    many situations, but makes the assumption that it is feasible for the
>    two operators to simultaneously publish slightly different versions
>    of the zone being transferred.  In some cases, such as with TLD
>    registries, operational considerations require both operators to
>    publish identical versions of the zone for the duration of the
>    transition.  This document describes a modified transition procedure
>    which can be used in these cases.
>

2.4.  The Procedure
Second paragraph under "Signing Migration",
"ganinig" -> "gaining"

In "Post Migration"
"severs" is correct, but it looks so much like a common misspelling of
"server" that I would replace it with "stops" or "breaks".

-- 
Bob Harold

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 3 Nov 2016 09:04:01 -0700

On 3 November 2016 at 08:59, Bob Harold <[email-masked]> wrote:

> Thanks.  I've fixed both of those in the document.

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 9 Nov 2016 15:03:00 +0100

Hi Matt,

I cannot help noticing that draft-pounsett-transferring-automated-dnssec-zones is providing the same solution as an earlier draft draft-koch-dnsop-dnssec-operator-change.
This draft has already gone through a review process, and is considered to be done content wise by the authors.

The reason why draft-koch-dnsop-dnssec-operator-change has never made it to WG adoption in DNSOPS is because of IPR that is now also targeting your draft.
There is currently discussion on this IPR on the REGEXT mailinglist because draft-ietf-eppext-keyrelay, which is the standardization of the provisioning parameters for this secure operator change concept is stalled for a long time as well because of this IPR.

Can I ask you how your draft is different from draft-koch-dnsop-dnssec-operator-change to justify a new attempt?
Wouldn’t the IPR pose the same adoption issues as draft-koch-dnsop-dnssec-operator-change?

The authors of draft-koch-dnsop-dnssec-operator-change are willing to revive the draft and ask for WG adoption by DNSOPS as well.
As co-author of that draft and the original inventor of the secure dns-operator change method, I’m open to see how that draft can be improved by your attempt, and see if we could work together to get this concept described in an Informational RFC.

draft-ietf-eppext-keyrelay is stalled in IESG review for 328 days now, and I wouldn’t want the DNSOPS WG to waste the same time while the IPR issue is not resolved.
Instead, I think it would be wise to jointly address both the Informational concept description and provisioning solution and if members of DNSOPS have any input to the IPR discussion on the REGEXT mailinglist, I would invite them to contribute.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

Op 31 okt. 2016, om 04:49 heeft Matthew Pounsett <[email-masked]> het volgende geschreven:

> Hi all.
> 
> I've submitted an update for the below draft which I'd like the working group to eventually consider for adoption.  If there's time in the agenda, I'd like to ask the chairs for some time to discuss this in Seoul.
> 
> As with the previous version, I'm looking for some specific feedback on a few things.
> 
> 1) I believe this draft represents operational experience that could be added to RFC6781.  While it doesn't (intentionally) change anything in 6781, I think the additional operator change procedure justifies the "updates" meta-data in the draft.  With the increase in gTLDs and the expected future increase in gTLD transfers I think it's important to put this information in front of operators searching for advice, which makes having it appear as a link from the 6781 meta-data important.  I'd like to get the group's feeling on that.
> 
> 2) RFC 6781 does not explicitly describe the timings of each step in the operator change procedure, leaving that as an exercise for the reader to obtain by reading earlier sections of the RFC.  The -01 version of this draft followed that style for a couple of reasons: first, so as not to unnecessarily duplicate any information; second, to avoid unintentionally introducing any ambiguity or update to the information in 6781.  I've been of two minds on that, however.  I felt that the aim of this draft–to provide advice to inexperienced operators–was not well served by leaving a prose description of the procedure out.  With the recent publication of errata for § 4.1.2, my opinion has tipped slightly the other way, and so I've added text to describe the steps and their timings.
> 
> 3) I don't believe this draft raises any *new* security considerations, so I've done my best to incorporate by reference the security considerations from 6781.  I'd like to know your thoughts on this as well.
> 
> 
> Subject: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt
> A new version of I-D, draft-pounsett-transferring-automated-dnssec-zones-02.txt
> Title:          Change of Operator Procedures for Automatically Published DNSSEC Zones
> URL:            https://www.ietf.org/internet-drafts/draft-pounsett-transferring-automated-dnssec-zones-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-pounsett-transferring-automated-dnssec-zones/
> Htmlized:       https://tools.ietf.org/html/draft-pounsett-transferring-automated-dnssec-zones-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pounsett-transferring-automated-dnssec-zones-02
> 
> Abstract:
> 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
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 12 Nov 2016 11:14:55 +0900

On 9 November 2016 at 09:03, Antoin Verschuren <[email-masked]> wrote:

> Hi Matt,
>
> I cannot help noticing that draft-pounsett-transferring-automated-dnssec-zones
> is providing the same solution as an earlier draft draft-koch-dnsop-dnssec-
> operator-change.
> The reason why draft-koch-dnsop-dnssec-operator-change has never made it
> to WG adoption in DNSOPS is because of IPR that is now also targeting your
> draft.
> There is currently discussion on this IPR on the REGEXT mailinglist
> because draft-ietf-eppext-keyrelay, which is the standardization of the
> provisioning parameters for this secure operator change concept is stalled
> for a long time as well because of this IPR.
>

I don't actually see the overlap.  Although perhaps I'm just missing
something.

Suzanne pointed draft-koch-dnsop-dnssec-operator-change out to me right
after my talk at the OARC meeting last month.. my first quick scan of it
and my more recent (this morning) closer look suggest to me that it is
dealing with the problem of moving a signed zones between non-cooperating
registrars.   One of the assumptions of the documented procedure is that
the DNS operators are not sharing DNS zone data, for example.

draft-pounsett-transferring-automated-dnssec-zones's basic assumptions are
that the DNS operators are cooperating, and that the principle requirement
for using the procedure is that they must publish the same zone throughout
the procedure, which implies an active zone transfer (or an analogue) at
every stage.

It seems to be that these two drafts are attempting to solve different
problems.

>
> The authors of draft-koch-dnsop-dnssec-operator-change are willing to
> revive the draft and ask for WG adoption by DNSOPS as well.
> As co-author of that draft and the original inventor of the secure
> dns-operator change method, I’m open to see how that draft can be improved
> by your attempt, and see if we could work together to get this concept
> described in an Informational RFC.
>

I'll defer on answering this until we resolve whether the documents
actually overlap. :)    If they do I have no problem dropping my draft and
contributing to draft-koch-dnsop-dnssec-operator-change instead.. but if
they are actually solving unrelated problems then I'm not sure I see the
value in a merge.

>
> draft-ietf-eppext-keyrelay is stalled in IESG review for 328 days now, and
> I wouldn’t want the DNSOPS WG to waste the same time while the IPR issue is
> not resolved.
> Instead, I think it would be wise to jointly address both the
> Informational concept description and provisioning solution and if members
> of DNSOPS have any input to the IPR discussion on the REGEXT mailinglist, I
> would invite them to contribute.
>

I'm brand new to the IPR issue, so these comments probably aren't well
thought out.  I noted when the IPR claim first appeared on my draft that
the same patent application is used in a claim against RFC6781.  I had
thought that the RFC had gone ahead despite the claim, and therefore it
wouldn't be a big problem for my draft, but having a closer look makes me
think that IPR claim may have appeared after publication.

I've seen the discussion in REGEXT and the comments from Scott about the
holdup in attaching a licensing intention to the IPR claims.  It seems to
me that it shouldn't be hard for Verisign to declare their intention should
their patent(s) be awarded.  If they aren't awarded then those licensing
intentions become irrelevant, and if they are awarded then.. well.. we know
in advance what Verisign's intentions are.   I don't understand why this is
a problem, but I Am Not A (Patent) Lawyer.

---

From: Antoin Verschuren <[email-masked]>
Date: Sun, 13 Nov 2016 16:05:49 +0100

Op 12 nov. 2016, om 03:14 heeft Matthew Pounsett <[email-masked]> het volgende geschreven:

Hi Matt,

> I don't actually see the overlap.  Although perhaps I'm just missing something.
> 
> draft-pounsett-transferring-automated-dnssec-zones's basic assumptions are that the DNS operators are cooperating, and that the principle requirement for using the procedure is that they must publish the same zone throughout the procedure, which implies an active zone transfer (or an analogue) at every stage.
> 
> It seems to be that these two drafts are attempting to solve different problems.

Ok, I do see the differences now, and the overlap.

draft-koch-dnsop-dnssec-operator-change describes the proces of synchronizing the minimum number of records needed between a gaining and lozing DNS-operator in order for the DNSSEC chain of trust to remain intact during a zone transition without exchanging private keys. It considers all other records that need to be synchronized for services to remain intact out of scope, as there is no difference in synchronizing them when the transition were to be done without DNSSEC. And in practice most of the time the purpose of a transition is because those records will change after the transition anyway. So it only describes the minimum that needs to be done so either zone data will not become insecure before, during or just after a transition, and how this process can be automated for every domain transition independent if other records change or not. It only prevents the domain from becoming unavailable due to validation errors.

Your solution describes the process of keeping a maximum number of records synchronized, -including those records needed for the chain of trust to remain intact-, but also not exchanging private keys, assuming that the services for the domain do not change after the transition. Some records like SOA, NS, signatures and private keys always change during a transition though.

So draft-koch-dnsop-dnssec-operator-change is a subset of your draft, only dealing with DNSSEC records, but includes text on how to automate the registration process for those minimum number of records to make it a common practice, and what to do when DNS operators are not cooperating to bail out of that process with as little damage as possible.

> I'm brand new to the IPR issue, so these comments probably aren't well thought out.  I noted when the IPR claim first appeared on my draft that the same patent application is used in a claim against RFC6781.  I had thought that the RFC had gone ahead despite the claim, and therefore it wouldn't be a big problem for my draft, but having a closer look makes me think that IPR claim may have appeared after publication.

Verisign claim that they have IPR on the process of changing a dns operator (called Hosting provider in the patent) for a DNSSEC zone while keeping the chain of trust intact.
That includes your and our solution as well as any process that describes a transition under DNSSEC including supporting provisioning processes like EPP.
They claim in their patent application (so not yet approved):
-That they invented this process for the first time in 2011.
-That this process is a novelty and not common sense.

Since there is prior art from before 2011, and there is sufficient doubt that the process is more common sense for people that understand DNSSEC in stead of a novelty, the patent application has been rejected twice by the European Patent Office. But a patent application is a long-lasting process, and allows for appeal processes to rejections that can take years. During this appeal process it is unclear which (if any) of the claims is ever to be granted, and so no license terms are yet given by Verisign.

As RFC 3979 says, it’s hard to give guidance to best current practices if no license terms are known for an IPR claim.
That’s why there was hardly support for draft-koch-dnsop-dnssec-operator-change to be adopted by DNSOP 4 years ago, and why there is hesitation in REGEXT to making statements on why the standards track document draft-ietf-eppext-keyrelay should ignore the IPR claim. RFC6781 was already a DNSOP document before the IPR claim was submitted.

- --
Antoin Verschuren