> 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).
>> o Check that if the zone uses RSA, the KSK and ZSK are at least 1280
>> bits and at most 2048 bits. This may be controversial, but for new
>> deployments RSA <= 1024 bits is widely considered too weak, and RSA
>> with more than 2048 bits creates signatures that are often too large
>> for reliable UDP transport.
>
> 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???
>> 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.
You may not have seen my posts to dns-operations and this list about the issues
with iteration counts that exceed 150. The tl;dr version is don't do that.
Catching mistakes at registration time is our best opportunity to maintain the
hygiene of the ecosystem.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
