On 18.07.12 19:30, Vernon Schryver wrote:
} From: Daniel Kalchev<dan...@digsys.bg> } Obviously, e-mail authentication is not appropriate, as is any in-band } authentication as well. It's not clear to me that e-mail authentication using something like https://www.ietf.org/id/draft-hoffman-dane-smime-03.txt "Using Secure DNS to Associate Certificates with Domain Names For S/MIME" is less secure than commercial PKI certificates. Of course, if you've lost your key files, it might not work very well. But in the future when (and if) your HTTP authentication also relies on DNS (e.g. DANE), ...
The trouble is with any in-band authentication. When you break DNSSEC, and you require DNS in any form in order to communicate, and especially to authenticate the other party -- obviously you can't trust it anymore.
} For example, while implementing DNSSEC back in 2007, we have made it } mandatory in the BG registry to use qualified electronic signatures in } order to manipulate DNSSEC. What do you define as a qualified electronic signature? What do you do for key distribution? HTTPS with commercial PKI is far better than unauthenticated, trivially forged mail, but it's not exactly secure.
I was curious how this could be interpreted, as it might be not widespread. In our case it is defined as non-repudiation signature with an officially issued digital certificate. There is no key distribution concerning the registry/registrar in this case, it is all external (out of band, essentially out-of-Internet). The "security level" aspect of course could be debated, but is in fact irrelevant in this discussion -- important is that this is an out-of-band authenticator, not related to DNS in any way.
} About the only operation you can do without } it is "turn DNSSEC off" and for this to work you need other than e-mail } authentication. Why should turning DNSSEC off be easier than adding or removing DS RRs? I understand that turning DNSSEC off is very useful in emergencies, but it also sounds very useful to your adversaries.
This is indeed a temporary solution. Ideally, everything should be authenticated out of band. When things break, you cannot rely on the in-band communication.
But, as long as NS records and other registration data could be communicated "less securely", the same should be valid for "turn DNSSEC off".
Why "turn DNSSEC off" is an special case? Because, with DNSSEC, there is end-to-end validation that can be employed by various applications levels and an DNSSEC enabled domain can be considered "secure". When DNSSEC is off for the domain, it will become "insecure" and there will be no confusion. Also, if NS changes can happen with less strict authentication checks, it is entirely possible for adversaries to just change NS records, thus making your DNSSEC setup invalid.
For this reason we also have "certificate-only" flag, which if set disables any DNSSEC manipulation, including turning off when not using certificate authentication.
In theory, mail management of DNSSEC could be better than standard DNS web management pages.
Note, I did not specify certificates are used on web forms. We use them in e-mail and in our RegRR (EPP extension) protocol and not only for DNSSEC.
The use of non-repudiation certificates makes things much, much simpler. The only trouble is, these are not particularly widespread around the world...
Daniel _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
