Am 07.11.2014 um 19:19 schrieb Michael Ströder:
li...@rhsoft.net wrote:
Am 07.11.2014 um 18:22 schrieb Michael Ströder:
Viktor Dukhovni wrote:
The rationale for the DANE work is in:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-1.3
I've already read/analyzed all DANE related RFCs and almost all drafts in
detail. Also some IETF presentation slides.
As already mentioned on the IETF DANE WG list:
The main obstacle is currently lack of DNSSEC deployments.
And personally I strongly dislike the DNSSEC auto-signing people usually
implement in their DNS servers
how else do you imagine to maintain 500, 1000, 10000 signed zones
Those numbers above may be impressive for you but not for me.
it's not a matter of "impressive"
it's just a matter of maintainable or not
while you
also are enforced for repeatly key changes and if you make one mistake in that
context one or all zones are dead?
Well, besides signaling mandatory use of TLS the promise of DNSSEC/DANE is to
mitigate all the risks leading to real security incidents of existing X.509
PKI. But note that most attacks were conducted through crappy RA interfaces.
So ask yourself:
If everybody uses the same sort of crappy registration interfaces for their
DNS entries while simply auto-signing DNS zone entries. Is there a real chance
to achieve the goal?
does everybody?
i doubt!
and even if you are talking about the interfaces to the registry for the
key rollout / change - they have no access to your nameservers and if
they are compromised dnssec would just fail and so any delivery
i doubt the same way as nobody else is using the same interfaces for
DNS, EPP, FTP, SFTP, EMAIL, SA as i do and as i did for all other
services i would and will implement the signing stuff myselft when there
is enough time to start dnssec in context of different TLD'S and most
customer domains have different TLD's as the main nameservers
why i would do that? because until now i did not see any ready-to-use
backend software with the needed automation, transitions and integration
in existing workflows and that hardly will change
