Subject: Re: trying to close Editor's Question Q-29

From: Jim Reid <[email-masked]>
Date: Wed, 11 Feb 2004 10:24:09 +0000

>>>>> "Ted" == Ted Lindgreen <[email-masked]> writes:

    >> > checks were successful, depending on local policy, to 
    >> > cope with small clock variations or network delays".
    >> 
    >> I think a definition of "small" will be needed. How about using
    >> the same fudge factor TSIG allows for skewed clocks?

    Ted> Roy pointed out that there is no need for fudge, as (other
    Ted> than with TSIG) one can (and should) use overlapping periods.
    Ted> Therefore, I take back my comment and proposal above.

I take back mine too. Thanks for helping to stop the discussion doing
down that particular rathole.

    Ted> It is clear that outside the validity periods a SIG is meant
    Ted> to be not valid. This is what the zone-administrator wanted
    Ted> and configured.

Indeed. I overlooked this basic truth.

    Ted> And I support Sam's suggestion that: "SHOULD be treated as
    Ted> bogus" is sufficient.

This can't be right. Roy's given good technical reasons for that. And
using a SHOULD makes validation optional. Logically, this is very bad
as it provides a get-out. To repeat my earlier question, why bother
with DNSSEC validation if failures can be disregarded and substituted
by other (unspecified) security checks?

It is beyond credibility that this WG could toil over DNSSEC for 7? 8?
years now and come up with a spec with a gaping hole that's so big
someone could drive a fleet of trucks through it. If the draft leaves
enough wiggle room to make validation optional, why bother validating
or signing anything?

Suppose Microsoft (say) use this loophole to avoid implementing
validation. [Remember they're good at finding ways to wiggle out of
supporting useful stuff that isn't mandatory to implement.] After all
their desktops would be free to use some other security check: that's
what the spec currently says. This would mean 90-something% of the
internet will not get any benefit from DNSSEC and that's a *massive*
disincentive for deploying it. Speaking as a DNS administrator,
there's no way I'd go through the pain of signing my zones or doing
key rollover if nobody's going to be compelled to validate them.

    Ted> IMHO: Adding anything else is unnecessary (it's already in
    Ted> RFC 2119) and only asking for trouble and endless
    Ted> discussions.

Isn't asking for trouble and endless discussions what DNSSEC is all
about? :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Wed, 11 Feb 2004 12:54:35 +0100 (CET)

On Wed, 11 Feb 2004, Ted Lindgreen wrote:

> [Quoting Samuel Weiler, on Feb 11,  9:19, in "Re: trying to close  ..."]
> .....
> > Repeating what I said when I started this discussion on 15 January:
> >
> > I think SHOULD is perfectly correct.
>
> is 100% correct. (Please read RFC 2119 first if you disagree).
>
> And I support Sam's suggestion that:
>    "SHOULD be treated as bogus"
> is sufficient.
>
> IMHO: Adding anything else is unnecessary (it's already in RFC 2119)
> and only asking for trouble and endless discussions.

Ted, Miek, Sam, anyone

Could you please state what those 'valid reasons' or 'particular
circumstances' are that can not be satisfied outside the DNSSEC
protocol to justify a change to SHOULD ?

Roy

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Feb 2004 22:20:33 +0900

> protocol to justify a change to SHOULD ?

As you ask anyone else, there absolutely are no circumstances
not satisfied by plain DNS.

That is, DNSSEC is unnecessary.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 12 Feb 2004 07:40:31 +0900

Ted Lindgreen wrote:

>>I think a definition of "small" will be needed. How about using the same
>>fudge factor TSIG allows for skewed clocks?

> Roy pointed out that there is no need for fudge, as (other than
> with TSIG) one can (and should) use overlapping periods.

Wrong. There must be a system wide requirement on the
minimum overlapping periods for rollover.

The period is also applicable to make expiration of some data
certain. That is, source of data must be aware that data is
valid even after cryptographic expiration for the maximum
allowable clock error of source and clients..

Another point related to expiration is that time source must
be secure, that is, is locally reliable source or from remote
reliable source with cryptographic security. While actual
mechanism is variable, it is important to explicitly
outlaw such behavior as just accepting GPS derived time.

						Masataka Ohta