On Fri, 16 Nov 2012, Ben Laurie wrote:
Because there are DNSSEC keys to back the time slots used, and
without it, the data can and should be rejected.
This argument is circular: clearly if no-one ever gets control of keys
for your domain, you don't have a problem. Validity times are
irrelevant.
If someone does get control, they control validity times, no?
If someone obtains your private keys, there is no need to forge anything
or issue any new certificates, they just run a copy of your private
key/cert on their MITM box. CT can't help you there either. If attackers
get your private DNSSEC keys (which shouldn't even be online, and surely
much harder to obtain compared to the TLS private key) you are lost.
You have a lot of faith in a mechanism that is not designed to provide
a globally consistent view. How does DNS prevent bad actors from
showing local views of the DNS? (Hint: it doesn't).
The root key protects me against that. And the TLD key. Sure, if I'm
using some untrusted national TLD which might be overwriting my parent
NS/DS set, again you are in a no-win situation. Best you can do is
monitor your own zone, and possible carry your own domain's trust
anchors with you. And these same players would simply prevent you from
accessing the CT services as well.
This is precisely what CT does, and is exactly the value it adds to
this kind of system.
As for CT vs DANE, it is precisely because DNS does not provide a
robust infrastructure that DANE cannot be allowed to override CT.
So Diginotar will submit a new cert for me to the CT, and we're back at
square one?
This
can be fixed by making DANE use some kind of equivalently strong
transparency. I agree with others that this is probably better applied
to DS records than to TLSA records.
While I agree that it won't hurt to log and audit DS records to see if
verisign or the USG really is signing their own records with the root or
.com keys, I still believe those two parts are the most secure players
I know to delegate some trust to. The real weak points of DNSSEC will be
the dns operators of the zones and the registrar webgui's for making
zone changes. In fact, I would probably rather trust the root key, then
most CT audit people - and it would come with less false positives due
to the middle man delays.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane