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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
