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

From: "Scott Rose" <[email-masked]>
Date: Tue, 10 Feb 2004 09:01:28 -0500

Q-29  Resolver handling of expired RRSIGs

So far, there doesn't seem to be a solid consensus on the following wording:

> >
> > "SHOULD be rejected, but MAY use RRSIGs if other security
> > checks were successful, depending on local policy".
> >

To replace the current text that states resolvers MUST reject out of date
signatures.  There is no time limit in the original question post, but the
editors would like to see some resolution before the I-D cutoff date.
Personally, I'd like it to be Fri. 13th if possible

Please post your opinion if you haven't already.  Or if you have further
comments on the text, or substitute text.

--
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: Jim Reid <[email-masked]>
Date: Tue, 10 Feb 2004 15:05:05 +0000

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:

    >> checks were successful, depending on local policy.

    Miek> I support the above text. A 'MUST' is way to strong. If one
    Miek> says MUST on this timing issue, what's next: MUST run ntp,
    Miek> MUST NOT fiddle with the local time?

I reluctantly support the text, but not Miek's justification for
it. Correct synchronisation is vital for DNSSEC so saying the clocks
MUST be aligned is not unreasonable. How that gets done is out of
scope. The DNSSEC protocol shouldn't need to know or care how that
synchronisation happens and so shouldn't say anything about that.

However I worry that by only saying "SHOULD be rejected" for expired
RRSIGs, this WG could be shooting itsefl in the foot again. The text
seems to be saying that if DNSSEC validation fails but some other
security check (like what?) works, it can be OK to use an answer that
the resolver knows didn't validate properly. Or isn't valid any
more. If that's really the case, why bother deploying DNSSEC or
keeping keys and signatures up to date? After all some other
unspecified security check can be used instead. And how can these
hypothetical security checks be made to interwork? Do I tell my
resolver to accept something on the say-so of Miek's server even
though his server was unable to do DNSSEC validation of that data?

How about the text below?
	.... SHOULD be rejected, but MAY use RRSIGs. In certain
	circumstances local policy MAY consider this to be
	acceptable behaviour, for example if other security checks on
	the data have been successful. The consequences of such a
	policy need to be carefully assessed.

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 10 Feb 2004 16:18:40 +0100

[Quoting Miek Gieben, on Feb 10, 16:01, in "Re: trying to close  ..."]
> [On 10 Feb, @15:39, roy wrote in "Re: trying to close Editor's Q ..."]
> > I want validation to BREAK when it is way passed/before the
> ^^^^^
> making the issue local policy IMHO... 

No, that is the local policy at the validator-side, Roy was talking
about what he wants from the signers perspective.

While I agree with Roy on "way passed/before" time difference, I
also agree with the people at the workshop that argued that some
slack is needed to cope with small clock variations and/or
network delays.

Perhaps we can settle this dispute with an addition like:

  > > > checks were successful, depending on local policy, to
	cope with small clock variations or network delays".

-- ted

---

From: Miek Gieben <[email-masked]>
Date: Tue, 10 Feb 2004 16:20:51 +0100

[On 10 Feb, @16:05, Jim wrote in "Re: trying to close Editor's Q ..."]
> though his server was unable to do DNSSEC validation of that data?

If I were to browse the web and my resolver would tell my browser:
"this data is bad, because the SIG expired 10 minutes ago" (suppose
it can tell that to my browser), it would be pretty neat if I could
still check out the (faked) website on the Internet. Or not?

> 	policy need to be carefully assessed.

anything without the MUST has my support,

grtz
      Miek

---

From: [email-masked]
Date: Tue, 10 Feb 2004 16:31:39 +0100 (CET)

On Tue, 10 Feb 2004, Jim Reid wrote:

> >>>>> "roy" == roy  <[email-masked]> writes:
>
>     roy> I want validation to BREAK when it is way passed/before the
>     roy> expire/inception time. I really don't want users of my data,
>     roy> whereever they are, whatever the usage is, be replayed with
>     roy> expired signatures of a stolen key.
>
>     roy> If this is going to be degraded to SHOULD, the system is less
>     roy> secure.
>
> I agree with this in principle.

Okay.

> However there may be cases where data that doesn't validate might need
> to be used to bootstrap the validation process.

OOB is the only way.

> Suppose your key gets compromised.

The whole system breaks at this point.

> You withdraw it immediately and re-sign your zone with a new key. So
> far, so good. Now my server is caching a SIG for your zone's NS RRset
> generated with the old key. Should my server query those NS records to
> try and get your new key or wait for them to expire from my cache?

Wait for the expire time. Until then, all bets are off. There is no
short-cut-local-uptimisation here. If your key is stolen by ScriptKiddy,
he'll generate new keys/sigs and update caches for you.

The only way caches are protected against replay is current time check. It
is part of the crypto-layer.

Roy

---

From: Jim Reid <[email-masked]>
Date: Tue, 10 Feb 2004 23:48:08 +0000

>> However there may be cases where data that doesn't validate
    >> might need to be used to bootstrap the validation process.

    roy> OOB is the only way.

Indeed. And that's what the original text was hinting at when it spoke
about "other security checks".

    roy> The only way caches are protected against replay is current
    roy> time check. It is part of the crypto-layer.

In that case, a MUST is needed, not a SHOULD.

Oh how I *hate* DNSSEC...

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 11 Feb 2004 10:24:08 +0100

[Quoting Jim Reid, on Feb 11,  0:45, in "Re: trying to close  ..."]
> >>>>> "Ted" == Ted Lindgreen <[email-masked]> writes:
> 
>     Ted> While I agree with Roy on "way passed/before" time
>     Ted> difference, I also agree with the people at the workshop that
>     Ted> argued that some slack is needed to cope with small clock
>     Ted> variations and/or network delays.
> 
>     Ted> Perhaps we can settle this dispute with an addition like:
> 
> 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.
Therefore, I take back my comment and proposal above.

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

Remains the question of wording what to do with such a SIG in the
sense of RFC 2119. Reading RFC 2119 again, I think that what Sam
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

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 11 Feb 2004 14:43:13 +0100

[Quoting [email-masked], on Feb 11, 12:54, in "Re: trying to close  ..."]
...
> 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 ?

I can think of several circumstances one still wants to see the
returned info when the signatures fail, but the most clear one
is probably: when debugging a lookup problem.

This seems to me a typical example of what is meant by the wording
in RFC 2119 for "SHOULD".

In contrast, the wording of "MUST" in RFC 2119 makes debugging
impossible, and that is not what we want, I think.

-- ted

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 11 Feb 2004 15:34:17 +0100

[Quoting "Scott Rose", on Feb 11, 15:10, in "Re: trying to close  ..."]
> If one is debugging DNSSEC, it would make more sense to turn on the CD bit
...

I'm not sure you have much experience with debugging or in general
problemanalysis, but I have ( > 25 years ), and I know it one of the
few things I'm actually good at:

 The very last thing one should do when analysing some strange
 problem is to flip a switch that changes the fundamental behaviour
 of the system you are analysing.

The CD bit is such a switch.

-- ted