In message <AANLkTinw3V51BVfnadCKQIL2fys9AkB3iHE_s231oUgL@xxxxxxxxxxxxxx>, Phil
lip Hallam-Baker writes:
> 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.
Yes adding data to the parent zone requires secure authenticated
communication. DS however are no diffent to NS. Both require the
same level of authentication. Yes it is subject to potential social
engineering attacks.
> 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'.
What's the liabilty for adding wrong NS records today? What I'm
trying to say is that DS records really don't change the problem.
You already need a system that is secure today regardless of what
data is being added.
> 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.
It really isn't that hard and it continues to get easier.
Tell named to use dnssec.
zone "example.com" {
type master;
file "master";
key-directory "/var/named/keys"; // where to find keys
auto-dnssec allow;
....
};
Create the keys where named can find them.
% cd /var/named/keys
% dnssec-keygen -f KSK example.com
% dnssec-keygen example.com
If you want you can use a HSM to generate and store the keys but I won't
detail that here.
Tell named to sign the zone with the keys.
% rndc sign example.com
Get the DS records to pass to the parent.
% dig @::1 +noall +answer dnskey example.com > junk
% dnssec-dsfromkey -f junk example.com
(this will extract the KSK and generate DS records for it)
If you don't want to use dig, you can get the records direct from the
master file or from the .key file generate by dnssec-keygen above.
If future we may add something like
% rndc getdsset example.com
to retrieve the ds set you send to the parent.
In the future "auto-dnssec create" will work and you won't need to call
dnssec-kegen and rndc but that requires a working /dev/random.
All the vendors are improving their products to make this easier.
> 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.
Well ask the registry. They have procedures today that should be
secure enough if they are doing their role correctly regardless of
whether the zone is signed or not.
> 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.
Well ask the registry. They have procedures today that should be
secure enough if they are doing their role correctly regardless of
whether the zone is signed or not.
> 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.
I'm not avoiding the question. I'm pointing out that the level of
security required to add data to a TLD should already be sufficient.
If it isn't you should have been complaining a long time ago. DS
is just more data that needs to be treated securely.
What DNSSEC does is secure the path back to the client.
Mark
--
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