Mark, If you didn't know I was right you would have addressed my actual argument rather than look for idiotic technical details that have no bearing on the issue itself. Yes, I know what a DS record is technically, and you know that I know. And you know that as far as liability is concerned putting a DS record in there is going to provide the location of a server, albeit by reference. Now I worked in the practices section of a major CA at the time that it was being established. I saw the development of the risk and liability mitigation strategy being developed first hand. I had frequent discussions on the matter with Michael Baum who was leading the effort. The expertise you are quibbling over can be found in a O'Rielly nutshell handbook. You are not quibbling to elucidate the issue, you are quibbling in the hope that by demonstrating I got something 'wrong' that you can ignore the issues that I am raising. Looking through your post I cannot see how you could be confused in the manner you purport to be confused. If there is going to be an unbroken chain of trust then at some point there has to be a point where the registry signs the domain owner key and it is damned obvious that that is the potential weak link in the chain. I don't want to be more specific that that because I know from previous interactions that if I try to be precise the response will be to try to distract with irrelevant nitpicking. What is worrying me is that if the liability issues had actually been considered, the answer to how my keys get into the domain would be 'go read document X.' because it really isn't possible to do the liability analysis on 'that will work the same way as it happens today'. It is very easy for the large registrars to sign the DNS zones for the servers they operate in house. It is not easy for the zones operated locally - which are the ones that people are most likely to want to DNSSEC. And before I place any reliance on this contraption, I want to know the full process by which the keys get into the domain and how each link in that process is secured. Because it would be rather sad if I spend time signing my zone and the link between the registrar and the registry is secured by the type of password an idiot would have on his luggage. If any registrar can validate keys in any zone in any way they please then that means that there really isn't any security here at all. I might think I am going to microsoft.com but mcolo registrar may have just hijacked the domain. Yes I know about domain locking, but I want to know what controls are in place to put it into effect. This avoidance of difficult questions is precisely the reason it has taken fifteen years to get to this point and the reason I do not have any confidence in DNSSEC being usable in the next ten. The same people responded in the same way when I brought up the NXT record issue and then we went through the same thing again with the EU privacy laws. Every time the response is to try to beat down any question. If my questions seem vague it is because they are about the real world and that is rather vague. On Tue, Jul 20, 2010 at 11:27 PM, Mark Andrews <marka@xxxxxxx> wrote: > > 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 > -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf