Subject: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-11: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 15 Dec 2015 03:41:26 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-eppext-keyrelay-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) The IPR declaration says that license terms will be available
"later." As things stand, I don't understand how the WG can have
made an informed decision in that case. I looked at the archive
and saw essentially no discussion, other than the announcement. I
also looked at the application and it's not crystal clear to me at
least that none of the claims are relevant. The shepherd write-up
also doesn't help me, but of course there may have been discussion
in a f2f meeting that is documented in minutes or something - I've
not checked for such, or I may have missed out on some list
traffic. Anyway, the DISCUSS is to ask did I miss stuff and if not
how can WG participants have rationally considered an IPR
declaration if the licensing information will only arrive "later"
after the document is approved to become an RFC?  (Note: If I am
explicitly told that this was considered and participants were ok
with the declaration even as-is, then I'll clear.) 

(2) So I can see at least two ways in which this kind of thing can
be done and you don't clearly say which this supports. Option (a)
would be for the gaining DNS operator to provide new public keys
to the losing operator for inclusion before a transfer so that
continuity is maintained during the transfer. Option (b) would be
where the KSK private material is not known by either
operator, but e.g. by the registrant. In the case of option (b)
the DNSKEY would be transferred from the losing to the gaining DNS
operator. (And the arrow in Figure 1 would be in the other
direction.) I think you need to be clear about which of these
cases is actually being supported and about the overall sequence
of events needed. (If you tell me that you really want to do
whatever is in draft-koch, then that's fine but then this draft is
probably premature and draft-koch would need to be a normative
ref.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I think I'm missing an overview of EPP here. The intro could
maybe do with a short para, and/or a pointer to something general.
(Ah, I get it in section 3 - the ref to 5730 might be better in
the intro.)

- general: I think it'd be better to talk about public key values
and not "key material" as the latter is often used to describe
secret/private values which aren't at issue here. (Or else
I'm mis-reading stuff:-)

- nit, p8: s/previously send/previously sent/

- Section 6: I'm surprised that you don't recommend or even note
that the gaining registrar/dns operator should be able to check
that the DNSKEY value it sees in XML is or is not the same as one
that is published in the DNS and verifiable there. Wouldn't that
kind of cross check be useful?

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 15 Dec 2015 12:01:17 +0000

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Stephen
> Farrell
> Sent: Tuesday, December 15, 2015 6:41 AM
> To: The IESG
> Cc: [email-masked]; [email-masked]; draft-ietf-eppext-
> [email-masked]; [email-masked]
> Subject: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-
> keyrelay-11: (with DISCUSS and COMMENT)
> 

I will see what I can do to have the declaration updated ASAP.

Scott

---

From: Rik Ribbers <[email-masked]>
Date: Tue, 15 Dec 2015 20:10:45 +0000

Hello Stephen,

My comment are inline.

Gr,
Rik 

> On 15 Dec 2015, at 12:41, Stephen Farrell <[email-masked]> wrote:
> 

I’ll wait for Scott Hollenbeck to update the IPR text. see https://mailarchive.ietf.org/arch/msg/eppext/h53yrXvbugHt9gCefOaUnJ62Ghg <https://mailarchive.ietf.org/arch/msg/eppext/h53yrXvbugHt9gCefOaUnJ62Ghg> 

> probably premature and draft-koch would need to be a normative

It is intended for option (a). The information transferred is the new DS-record or the new public keys depending on the server policy. See also more comments below.

RFC5730 is also mentioned in the abstract. 

> secret/private values which aren't at issue here. (Or else

See comment above; We chose the term DNSSEC key material after quite some discussion between the authors because you either talk about the DS-record or the public key.
Having re-read Section 2.1 on DNSSEC key material I see the reference to RFC5910 (DNSSEC provisioning through EPP) is actually incorrect (and might lead to your mis-read) . Currently it references section 4.2 This should be section 4 as the difference between DS-data an key data is explained in the introduction of section 4. I have updated the reference to section 4 in the working copy of the document.

> - nit, p8: s/previously send/previously sent/

Fixed in the working copy of the draft.

> kind of cross check be useful?

I agree that this is useful; proposed wording:

A client that uses this mechanism to send DNSSEC key material to another client COULD verify through DNS that the DNSSEC key material is added to the authoritative zone of the domain.

Please let me know what you think of this proposed wording.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 16 Dec 2015 16:48:53 +0000

> https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/

It will be early next year before Verisign will be able to provide an updated declaration due to the upcoming holidays and associated time off for involved people. Sorry for the delay.

Scott

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 16:59:18 +0000

Hi Scott,

On 16/12/15 16:48, Hollenbeck, Scott wrote:
> It will be early next year before Verisign will be able to provide an
> updated declaration due to the upcoming holidays and associated time
> off for involved people. Sorry for the delay.

Thanks for chasing this up and I fully understand. I'll chat
with Barry about how best to handle stuff in the meantime.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Dec 2015 14:33:36 +0000

Hiya,

> I’ll wait for Scott Hollenbeck to update the IPR text. see https://mailarchive.ietf.org/arch/msg/eppext/h53yrXvbugHt9gCefOaUnJ62Ghg <https://mailarchive.ietf.org/arch/msg/eppext/h53yrXvbugHt9gCefOa…

Right, this seems to be in-work which is fine.

> It is intended for option (a). The information transferred is the new DS-record or the new public keys depending on the server policy. See also more comments below.

Ok, so it's option (a) which is fine. But don't you need to
say that in the document? I initially assumed you were doing
(b) which lead to a confusing read. I'd suggest adding a bit
of text like this near the start:

"This specification describes a way to use EPP to allow a
gaining DNS operator to send new public keys to a losing
DNS operator. Having those new keys signed in the DNS before
transitioning to the gaining DNS operator means there need
not be any gap in service when new private keys (at the gaining
DNS operator) are used to sign DNS records. While there are
other ways of managing keys during transitions, only this
method is described in this specification."

Cheers,
S.

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 17 Dec 2015 15:59:39 +0000

Hello Stephen,

counter proposal:

In this document we define an EPP extension to sent DNSSEC key material 
between EPP clients. This allows DNS operators to bootstrap automatically, reliable and 
securely the transfer of a domain name while keeping the DNSSEC chain of trust intact. 

Gr,
Rik

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Dec 2015 16:03:38 +0000

> securely the transfer of a domain name while keeping the DNSSEC chain of trust intact. 

So that doesn't address the exact point that confused me
which was that you're only defining how to do things in
one way where new public keys go from gaining -> losing.
That is the crucial point you need to make.

Secondly, acking that there are other ways in which it
can be done would be good too.

S.

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 17 Dec 2015 16:15:45 +0000

Stephen

> can be done would be good too.

The proposed text is for section 1, your points are addressed in section 1.2.

Gr,
Rik