[ntp:questions] Re: restrict lines
davids at webmaster.com
Tue Mar 15 01:28:28 UTC 2005
"Brad Knowles" <brad at stop.mail-abuse.org> wrote in message
news:mailman.3.1110840467.588.questions at lists.ntp.isc.org...
> At 2:17 PM -0800 2005-03-14, David Schwartz wrote:
>> Yes, exactly. You can't fix this problem anywhere but at its source.
>> might as well argue that we should never use domain names in any
>> with any security implications.
> Okay, go fix the entire Internet, then. Please report back when you're
That's exactly what needs to be done, and that's exactly what *is* being
> Meanwhile, the rest of the world has been learning the lesson over the
> past decade that name-based security is one of the stupidest ideas ever
Over no security at all, I'll take it.
>> On the contrary, it's if you depend upon IPs for your security that
>> get into trouble if things change.
> Yup, that's a problem. That's why you use public-key crypto. BIND learned
> this lesson years ago.
Right, except let's look at the present case. No security is avialable,
IP based security is available, crypto-based security is avaialable.
Name-based security, though trivial to offer, is not available.
>> If you really believed the argument
>> are making, you would have to object to the existence of pool.ntp.org,
>> it does the very thing you are complaining about.
> No, pool.ntp.org has nothing to do with security.
That's the problem. There is no security at all.
> That's a one-way name-to-IP address mapping, and there is no implied
> security that is claimed to be provided. In those situations, if your DNS
> cache is poisoned and you get sent to the wrong servers, then that's your
As opposed to if you use name-based securit, and then if you get sent to
the wrong servers it's someone else's?!
> As soon as you try to apply some security to this problem, you run into
> the fact that most members of pool.ntp.org do not have control over their
> reverse DNS, so they cannot change what name should be claimed for their
> IP address. You also run into the load-balancing and system monitoring
> problem, whereby an address that was in pool.ntp.org five minutes ago, is
> no longer in the pool.
I'm not sure I understand why that matters. There are any number of
implementations of name-based security that wouldn't suffer from these
trivial technical deficiencies. For example, one implementation would be
that any time a name is looked up to find a server or peer, a compare is
done of that hostname to the restrict lines. If a name match is found, then
that IP is given temporary permissions as configured in the restrict line.
It's easy to argue against a proposed capability if you imagine it with
> If you want to secure this, your *only* effective choice is to use
> public-key crypto.
This is based on a bizarre definition of "effective". The only effective
way to stop my car from being stolen may be to lock it in my garage, but I
still appreciate being able to lock the doors, even if it's not "effective".
For one thing, it's convenient. And it may, in some cases, be quite rational
to trade some security for some convenience.
>> Is it your position that name-based security is worse than no
>> at all?
> In this case, yes. It gives you a sense of false security, and you feel
> comfortable staying there instead of working on the real security problem.
It is amazing to me that you can draw this conclusion for all of the
millions of situations in which people may choose to use name-based security
>> Or would it be your position that NTP should be modified to make
>> impossible to configure it with no security at all?
> NTP already understands the concept of cryptographic authentication. That
> technique needs to be extended.
That doesn't answer the question.
If door locks on cars aren't an effective way to prevent them from being
stolen, shouldn't they be removed? If name based-security shouldn't be
added, if it had already been added, why shouldn't it be removed?
More information about the questions