On Sat, 10 May 2014, Warren Kumari wrote:
On Fri, May 9, 2014 at 7:29 PM, Nico Williams <[email protected]> wrote:
On Fri, May 9, 2014 at 6:12 PM, Phillip Hallam-Baker <[email protected]> wrote:
The simplest way to align things is to simply have a certificate
issued for the DNSSEC zone KSK and plop that in the log as normal.
Sure, each zone acts as a CA for its children. That works, I think.
The problem with that approach is that it does not make DNSSEC distinct
from the existing CA PKI. It will also not remove the cost factor of
getting a DNSSEC "certificate" from a "certified" CABforum member.
I have previously had some discussions about including DNSSEC / DANE /
self signed certs -- one of the objections / concerns was the threat
of someone DoSing the logs by making up data (there is a cost to a CA
cert, but I can create an infinite number of TLSA records or self
signed certs).
Cost should IMHO not become a verification factor. That's the whole
reason https hasn't been universally deployed to begin with. We should
not make the same mistake with DNSSEC.
The main incentive (that I can see) to DoS the logs would be for the
lolz[0], and so (IMO) the protection does not need to be very strong -
having someone have to solve a captcha or make a small payment (could
become a donation) would be enough.
Or just say that anyone who puts in more than X amount of DNSSEC CT
entries underneath themselves must run a public CT node themselves. So
if nohats.ca want to get more then X entries, or one of their
subzones/customers wants more than X entries, either they or their
subzone/customer will have to run a fully functional CT node. And if
the node goes down, their new entries will be refused.
Paul
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
