On 14 April 2018 at 17:05, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > On Apr 14, 2018, at 4:26 PM, Matthew Pounsett <m...@conundrum.com> > wrote: > > > > These are getting into name server quality checks, and not security > checks, which is the point of the acceptance testing. I don't agree that > these should be part of this document. > > If the registry operator is going to automatically upgrade previously > insecure delegations to DNSSEC, then due diligence to make sure that this > is not going to cause outages is advisable. Once a domain is signed, TLSA > and CAA lookups must succeed, or the domain may no longer receive email > from DANE-enabled sending MTAs, or be able to obtain certificates from > their CA, ... > > So I rather strongly feel that appropriate quality checks should be in > place, to protect both the registrant and the registry (dealing with > fallout from outages is best avoided). > Except that those are standard DNSSEC operations best practices, not even limited to CDS use, let alone a REST protocol designed for signalling that CDS should be scanned. Perhaps others can speak up about the applicability here, but I feel rather strongly that general operations best practices shouldn't be defined in a document limited to one corner case. That risks the advice case either not being applied elsewhere, because it's not in a general operations document and therefore not seen, or worse contradicting what goes into a general operations document. The security checks in this draft are there to help ensure that the parent can trust the update request. I believe going further than that is out of scope. I think if you want there to be guidance that parents should check on the quality of the child operations that should 1) come from DNSOP, not REGEX, and 2) be in a document about general DNSSEC operations. We currently ref out to draft-wallstrom-dnsop-dns-delegation-requirements in that section (we're hoping that draft continues to go somewhere so we don't have to import too much of its text directly, although it has been expired for a year now). You might want to submit some text there.. or angle for something that updates (or is a -ter for) RFC6781. > > > > While this is probably a reasonable thing to do, a registration > mechanism documented in REGEXT is not the place to do this. I think if > DNSOP wants such advice in a standard there should be a BCP document out of > DNSOP that defines it. > > Yes, this is a point for discussion. Still I think it would be bad to, > for example, introduce more domains with 512-bit RSA keys, or perhaps even > accept 1024-bit RSA > keys. There are many domains with 1536-bit KSKs and 1280-bit ZSKs, these > are I > think well chosen, though ECDSA P-256 (algorithm 13) is looking > increasingly like > an even better choice at present. > > Given that 1024-bit RSA is considered past its use-by these days, perhaps > limiting > automated upgrades to DNSSEC only to stronger keys is a good idea??? > But again, that's a general operations issue, and not one limited to this signalling mechanism. > > >> o Check that if the zone uses NSEC3 the NSEC3PARAM iteration > count is > >> at most 150 (regardless of RSA key size). Larger iteration > counts > >> are both inefficient and fragile in the face of algorithm > rollovers. > >> The optimal value is 0 (performs one round of SHA1, which is > enough to > >> deter casual zone walking). The most popular value is 1, which > is > >> very likely because it is slightly unclear whether 0 means no > hash > >> or (as is the case) just one initial hash. So hats off to the > >> operations that chose 1, they understand that the count should > be > >> low, and are careful to avoid edge cases. > > > > Again, I think this is out of scope of a document standardizing a > registration mechanism. Besides which, there are operators out there who > deliberately have a low iteration count because they don't care about zone > walking, and are only using NSEC3 for the opt-out capability. > > Here you misunderstood my point, I am suggesting a MAXIMUM of 150 and > recommending > 0 or 1, precisely because opt-out is mostly all that NSEC3 is useful for, > but one > or two rounds of SHA deter "casual" zone walking. > Yes, for some reason I got your intent backwards. I still think it's out of scope though... an iteration count higher than 150 does not constitute a trustworthiness problem for the parent.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
