[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis

[John R Levine <[e-mail]>]

I took a look and didn't find anything particularly troubling.  I agree 
that adding the new optional DNSKEY element doesn't need a version number. 
Getting rid of private certificates in favor of a CA signed cert for the 
HTTPS server makes sense.

On the other hand, I don't understand what the point of the new optional 
DNSKEY field in the XML is.  I see that IANA does not currently include 
it.

It's always been possible to retrieve the DNSKEY records from the live 
root and check that one of them matches the digest in the XML.  Is this to 
provide a way to remember the old DNSKEYs that have been rotated out of 
the root?  A sentence or two describing the motivation would help.

The third paragraph of section 3.2 describes a detached CMS signature. 
While I realize it's there in 7958, I don't see how it provides any 
security at all.  It's signed with an ICANN private key but there's no way 
I can see to tell the "real" ICANN CA from one that I just made up to sign 
my fake XML.  The useful security is the accredited CA signed HTTPS 
certificate described in the following paragraph, so I'd take the CMS 
signature out or at least note that it's trivial to defeat unless you have 
external knowledge about ICANN's private CA.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly