[Cryptography] Certificates and PKI

Paul Wouters paul at cypherpunks.ca
Thu Dec 25 13:54:06 EST 2014

On Wed, 24 Dec 2014, Viktor Dukhovni wrote:

>> that does not provide any proof for a parent stealing an entry from your
>> domain:
>> example.com. IN NS ns1.yournameserver.com.
>> example.com. IN DS 1234 8 2 <blob>
>> www.example.com. IN A
> Do you mean the parent pretending the delegation does not exist,
> and returning a signed answer rather than a referral?


> The parent can also actively deny the existence of DS records and
> make the child zone "insecure".  Signed denial existence of DS RRs
> at a delegation can be logged, when there is previous (not expired)
> evidence of DS records.

But that is easier spotted with a change od DS/DNSKEY. No need to
remember A records etc.

> However evidence of the parent serving the child zone, as if no
> delegation existed, is more difficult to accomodate in a transparency
> scheme.


>> The log
>> can only log, the clients/monitors however have some really hard
>> decisions to make to distinguish domain ownership change versus hostile
>> take-over.
> Surely for CT that distinction is not relevant.  CT exposes the
> change to anyone who cares, and they decide whether it is legitimate,
> and what they want to do about it.

In a way it is. False positives destroy the reliability of the system.
Like Certpatrol.

>> Additionally, DNS is supposed to work in a split-world, which will
>> trigger false positives to the logs unless you can inform the logs
>> of such split-view.
> Folks operating non-public DNS views, cannot make use of public CT
> logs at or below non-public delegations.

But the folks parents' could do this without their knowledge or consent.

> An "A" record takeover is more easily done with BGP or other on-path
> attacks at the network rather than DNS layer.  A more security-relevant
> "takeover" is for "TLSA" records.

The TLSA direct delegation beyond the zonecut is the same problem as the
A record. And I do agree monitoring for A record changes makes no sense
and one should stick to public mey monitoring (DNSKEY/DS/TLSA etc)


More information about the cryptography mailing list