ietf
[Top] [All Lists]

Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!

2010-07-21 18:27:51

In message 
<AANLkTinw3V51BVfnadCKQIL2fys9AkB3iHE_s231oUgL(_at_)mail(_dot_)gmail(_dot_)com>,
 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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>