In message <AANLkTillT7BXQ7lkdn0r1g10Q8iPNMbpgNgz6owgeGaZ@xxxxxxxxxxxxxx>, Phil lip Hallam-Baker writes: > On Tue, Jul 20, 2010 at 12:12 AM, Mark Andrews <marka@xxxxxxx> wrote: > > > > In message <AANLkTikni86AOABGKIB1_jOeQe0Ou4swpGrS8H1MbmrQ@xxxxxxxxxxxxxx>= > , Phil > > lip Hallam-Baker writes: > >> Being able to verify signatures is of no value. > >> > >> The system only has value when you can act differently according to > >> whether the signature verifies or not. > >> > >> I keep asking, but nobody will tell me how I get the keys for my > >> domains into the TLD. > > > > Firstly you get DS records into the TLD not DNSKEY records. Secondly > > it is/will be by a mechanism similar to how you get NS records into > > the TLD. In other words go ask your registrar when they are going > > to support adding DS records and stop complaining here. > > I am not asking about the TLD keys, I am asking about my keys. I will repeat myself. The parent zone has DS records added to it not DNSKEY records. Your keys are added to your zone so I presume you know how to update your zones. > And I really hope that the mechanism for handling the name holder keys > recognizes that registering a million keys is different to > distributing a hundred where all the parties know each other > personally. Well you know your parent or its agent (registrar). You hand the DS to them to publish. The rest of the world gets the DS from them. The only keys that have to be widely distributed are those for the root zone and that's a similar problem to distributing the list of root nameservers and their addresses. Millions of recursives server operators have managed that. > You would not be saying "go ask your registrar when they are going to > support adding DS records" if you didn't know that the answer was that > the registrars have made no commitment to deploy. Well pick one that does. GoDaddy does accord to reports I've seen. There are others that also support DS records. > Holding a key signing ceremony is not a new technological achievement. > It is being held now with great fanfare in the hope that if everyone > makes enough noise about how much momentum DNSSEC has that the > opposition of the registrars will somehow disappear. No one said it would magically fix things. It does however remove one of the more common excuses people have been using to not do the could of minutes work that is required to turn on DNSSEC. > I don't see why that strategy would work. I have certainly never seen > it work in the past. We go complain to your registrar. Say you will take you business away unless they add support and do it when they don't. > > This is not a technological problem. It is a business problem > > between you, your registrar and the registry. > > You are an engineer. If the technology does not meet the business > needs then you have failed. The technology is not the problem. It's getting the registrars to change their web forms to support adding DS records. That is the last step. EPP supports DS. The nameservers support DS. The clients support DS. Adding DS records is really no harder than adding NS, A and AAAA records that are required to make a delegation work. > If DNSSEC is not going to fail we need to re-engineer it to propose a > business model that actually works. Sitting on the sidelines and > shouting 'the technology is perfect damit, go make the business model > work', is not going to solve the problem. Nor is 'go away, my > technology is perfect, perfect I tell you'. > > What has me very worried here are the comments to the effect 'the > registrars are behind'. What if the registrars are not 'behind', what > if they have no interest in deployment or are actively opposed but > unable to say so openly while Cerf and co are saying that DNSSEC is > the historic solution to solve the problem of Internet security? Except they arn't all against it. Some have already started accepting DS records. > >> This is not a trivial issue. There is a question of liability to be > >> addressed. So far ICANN and VeriSign Registry Services have addressed > >> the issue by booting it down the chain. But the system as a whole > >> cannot work until there is someone willing to accept the liability and > >> for that to happen they are going to require tools to manage their > >> litigation risk. > > > > How is the liability different from that of accepting NS records? > > DS records don't magically change the liability. Stuffing up either > > NS or DS records will break the delegation. > > Yes they do. > > An NS record specifies the address of the DNS server No. It specifies the NAME of a nameserver. A/AAAA records specify the addresses. > A DS record specifies an intermediate certificate in the chain of > trust for authenticating any entity that is attached to the domain. And a registrar should be treating changes to NS, A, AAAA and DS records with a equal level of respect. They shouldn't be accepting changes from anybody. They should already be doing the level of checking needed for DS records for NS, A and AAAA changes. Afterall stuffing up any of these will break the delegation / allow it to be hijacked. > In the case of an NS record it is established that the design does not > provide security in the DNS layer and this has to be provided > independently via an end to end mechanism such as SSL with DV or EV > certs. You are confusing the trust level needed to add/change records to the database to that of the transport used to retieve data from the database. > In the case of a DS record the design is expressly designed to provide > for authentication of assertions relating to a domain name distributed > through the DNS. > > > --=20 > Website: http://hallambaker.com/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf