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: 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 ..."]
> 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

---

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

> comments on the text, or substitute text.

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

> 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: 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: 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: Samuel Weiler <[email-masked]>
Date: Wed, 11 Feb 2004 01:34:58 -0500 (EST)

Repeating what I said when I started this discussion on 15 January:

I think SHOULD is perfectly correct.

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

Using the language of Q-28 (which may change slightly), I think five
words are sufficient: "SHOULD be treated as bogus."  The MAY is
implicit.

>     roy> time check. It is part of the crypto-layer.
Jim> In that case, a MUST is needed, not a SHOULD.

Disagree.  This is a 2119 "SHOULD" -- ignore at your own peril and
only after due consideration (Really.  We mean it.), but you're not
hurting anyone other than yourself.

-- Sam

---

From: [email-masked]
Date: Wed, 11 Feb 2004 09:59:48 +0100 (CET)

> Repeating what I said when I started this discussion on 15 January:

Repetitive statements does not make your argument more true.

> I think SHOULD is perfectly correct.

You were wrong then, you are wrong now.

You wrote: "To accomodate local policy, I think these should be SHOULD
NOTs." in your january 15th mail.

You are using "local policy" as magic paint to ram your view of the
robustness principle into a validator. ANY policy that allows treating
expired signatures as valid is BAD policy.

The validator validates, checking the time stamp is part of the
validation. It's as old at 2065 (6.4 Secure Time). Its in 2535 (6.4
Secure Time). Why change it now ?

> words are sufficient: "SHOULD be treated as bogus."  The MAY is

Repetitive statement.
Repetitive statement.

> hurting anyone other than yourself.

The exact meaning of MUST applies perfectly:

MUST	This word, or the terms "REQUIRED" or "SHALL", mean that the
   	definition is an absolute requirement of the specification.

This is an absolute requirement. A dealbreaker. Protecting against replay.
If this is a SHOULD the system is less secure. I can sign data with a Very
Large Key and a Very Short Validity Period. If some implementation has a
switch that allows end users to TRUST MY DATA while MY DATA IS BOGUS due
to expiration, then that switch is illegal. If that switch is legal, all
bets are off.

Change local time as a workaround to have a system validate old
signatures. Don't hack the spec to allow for this.

Roy

---

From: Miek Gieben <[email-masked]>
Date: Wed, 11 Feb 2004 12:24:16 +0100

[On 11 Feb, @07:34, Samuel wrote in "Re: trying to close Editor's Q ..."]
> words are sufficient: "SHOULD be treated as bogus."  The MAY is

after reading 2119, I wholehearted agree that these 5 words are
enough,

grtz Miek

---

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