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

From: Miek Gieben <[email-masked]>
Date: Tue, 10 Feb 2004 15:18:35 +0100

[On 10 Feb, @15:01, Scott wrote in "trying to close Editor's Quest ..."]
> 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".
> > >
> 
> Please post your opinion if you haven't already.  Or if you have further
> comments on the text, or substitute text.

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

regards, Miek

--
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: Tue, 10 Feb 2004 15:39:17 +0100 (CET)

On Tue, 10 Feb 2004, Scott Rose wrote:

> 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
>

The issuer of the signature (signer) put a 'Only Use After/Before' stamp
on the data.. The signer obviously wants the validator to consider the
signature and data as valid within the specified time.

That implicates that the signer wants an expired signature to be bogus
(nee unsigned).

I want validation to BREAK when it is way passed/before the
expire/inception time. I really don't want users of my data, whereever
they are, whatever the usage is, be replayed with expired signatures of a
stolen key.

If this is going to be degraded to SHOULD, the system is less secure.

Roy

---

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

[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... 

grtz
      Miek

---

From: Jim Reid <[email-masked]>
Date: Tue, 10 Feb 2004 15:13:55 +0000

>>>>> "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. However there may be cases where data
that doesn't validate might need to be used to bootstrap the
validation process. Suppose your key gets compromised. 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?

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Feb 2004 08:44:28 +0900

>>>checks were successful, depending on local policy".

It effectively means that DNSSEC is unnecessary. So edit rest
of the draft to make it empty.

						Masataka Ohta

---

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Thu, 12 Feb 2004 14:58:43 -0500

>comments on the text, or substitute text.

Closure:

At this point the chairs see a consensus for continued use of
"MUST reject" wording.

         Olafur (acting WG dictator)

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 12 Feb 2004 17:09:44 -0500 (EST)

> At this point the chairs see a consensus for continued use of

(A very rough consensus, perhaps?)

Given the pending Q-28, I'm presuming that this will be "must treat
as bogus" or somesuch, right?

I'm surprised that those opposing this change aren't also objecting to
the Q-28 proposal.  The way I understand it, the Q-28 language
assigns all validation results to one of several states and then
suggests how the validator handle those by default.  If 2119 language
were in use, those suggestions would be SHOULDs.

-- Sam