Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Paul Wouters <[e-mail]>]

On Tue, 20 Mar 2018, Michael Casadevall wrote:

> Certificate Transparency works because specifically because the entire
> certificate is uploaded, and (assuming a valid cert) a SCT is generated
> which can be verified by cross-checking it against the log servers
> public key.
>
> Without the RRtypes logged, I'm not seeing how you're supposed to be
> able to audit them. In the case where a KSK is compromised, you could

Neither this nor certificate transparency protects against a (non-known)
private key compromise. In the case of CA's there are multiple entities
that can create a certificate that need to be audited. In DNSSEC, it is
only the zone or its parents that could create a rogue TLSA record.

> I'm likely missing something obvious, by only logging DS/NS, it would be
> impossible to determine if a private key is misused to serve fraudulent
> records which in my mind is a bigger and much more likely/common threat
> since one can simply attack a target domain and not try to compromise
> the root.

This is similar to the TLS server private key being compromised without
knowledge. That is not what is being protected.

> From a technical point of view, aren't there TLDs that as authoritative
> for second level domains as well? The specification likely needs a way
> to denote how many levels deep delegation can go. This also would be
> true in the case of delegation_only being used at a level above both the
> root and TLD zones.

In trying to keep this as simple as possible, the idea was to make this
concept as simple as possible. Making a promise about "every zone cut"
is much easier then making a promise to point to some more complicated
policy that might change over time, and then you have to log/audit the
changes to that policy as well.

For instance, you could have the DNSKEY flag mean "look for the
DELEGATE RRtype policy" and in there specify exceptions for your empty
non-terminals, but it just makes everything much harder.

> I know historically .name only allowed registration of third-level
> domains until 2009, and .uk up until 2014. I'm unsure if any of the TLDs
> still restrict and/or is authoritative for second-level domains as well.

If you run .example and have registrations in *.com.example and
*.edu.example, then the easy way is to create real zones for edu.example
and com.example.

> At a minimum though, the one case I know off hand of a TLD being
> authoritative for a second-level domain is that ICANN requires new gTLDs
> are required to publish a wildcard for 90 days when they're added to the
> root zone to help catch any name collisions.

If the software allows signing the wildcard and setting the
delegation-only flag that would mean the wildcard must be
treated as BOGUS, that would not be a problem. It would still
cause problems to be found with name collisions, except now the
name SERVFAILs instead of resolving to 127.0.0.53. Both will show
the name collision as a problem.

Paul