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

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/12/15 20:10, Rik Ribbers wrote:
> Hello Stephen,
> 
> My comment are inline.
> 
> Gr,
> Rik 
> 
>> On 15 Dec 2015, at 12:41, Stephen Farrell <[e-mail]> wrote:
>>
>> 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.) 
>>
> 
> 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> 

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

>> (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.)
>>
> 
> 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.


>>
>> ----------------------------------------------------------------------
>> 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.)
>>
> 
> RFC5730 is also mentioned in the abstract. 
> 
>> - 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:-)
>>
> 
> 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.
> 
>>
>> - 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?
>>
> 
> 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.
> 
>