Subject: Re: prohibiting use of expired RRSIGs

From: bill <[email-masked]>
Date: Fri, 16 Jan 2004 09:18:28 -0800 (PST)

> > >From records-06, section 3.1.5, first paragraph:
> >
> >    The Signature Expiration and Inception fields specify a validity
> >    period for the signature.  The RRSIG record MUST NOT be used for
> >    authentication prior to the inception date and MUST NOT be used for
> >    authentication after the expiration date.
> >
> > To accomodate local policy, I think these should be SHOULD NOTs.
> >
> > I can imagine some resolvers wanting to knowingly use expired RRSIGs.
> >
> 
> I think there is a danger if the specifications say it is ok to go "off the
> reservation" and accept certain errors.  Unless an application and user is
> willing to accept risky responses (example:  RRSIG verified, but time was
> off, or RRSIG in an algorithm the resolver cannot understand), it can
> request that, but it should be able to rely on a some base security checks.
...
> 
> I would rather see a base "MUST NOT accept expired SIG" as the default
> operation, and anything beyond that as an option an app can specify, rather
> than "SHOULD NOT" and have an application not be sure what the resolver is
> doing.
> 
> Scott
> > -- Sam

	perhaps its me, but some thinking leads me to beleive that
	we are mixing features/functionality here.  What if folks
	have a "stock" resolver (whatever the heck that is) and a 
	"validator", where the default is that the resolver "throws"
	data to the validator, which does the checking and then "throws"
	a response back to the resolver.  Much less change on the 
	part of the resolver (can impliment local policy) and then
	the validator can retain the "MUST NOT accept expired SIG".

	Or is this just too wierd?

--bill

--
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: "Scott Rose" <[email-masked]>
Date: Fri, 16 Jan 2004 12:44:20 -0500

----- Original Message ----- 
From: "bill" <[email-masked]>
> ....

nope, sounds like it could be a common set up.  I was probably blurring the
lines between resolver and validator too much there.  If the resolver throws
stuff to the validator, and the validator returns the answer, there would
have to be other info there if an error occurred so the resolver can make a
decision.

There is also the problem of a recursive resolver acting on behalf of a
stub.  If an expired RRSIG is encountered, what should the recursive
resolver pass back to the stub?  The stub has not said what kind of response
it is willing to accept.

Scott

---

From: bill <[email-masked]>
Date: Fri, 16 Jan 2004 10:12:48 -0800 (PST)

> resolver pass back to the stub?  The stub has not said what kind of response

	presuming a validator "module" - one could conceive that
	it would plug into the iterative/caching resolver and then
	the stub would behave the way it does today...

---

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 26 Jan 2004 11:36:51 -0500

Various people had written:
> >>MAY be configurable as to whether to accept expired records.  If
> >>configurable,  SHOULD be
> >>configurable to as to the maximum out of date expired 
> records can be to be
> >>acceptable.  And if configurable, MUST default to not 
> accepting expired
> >>records.
> > 
> > 
> > Much better, but this loses the main sentiment of the original,
> > namely that one MUST NOT or SHOULD NOT use out-of-date (expired or
> > not yet active) RRSIGs.  The text above would allow a 
> > non-configurable resolver to accept out-of-date records.
> 
> Allowing an insecure option is not appropriate.
> 
> If a protocol is allowed to be operated with less security, most
> people will do so and still believes they have advertised (full)
> security.

Ohta-san:
During the transition from DNS-today to DNS-with-signed-zones, many
compromises need to be made that allow for configurability without
denying DNS to users.  The challenge is doing that in a way that
does not lead to long-term security issues with DNSSEC.  However, 
in this case Mike StJohns correctly stated an issue with the language.
If Sam revises his language appropriately then that would lead to a
workable solution that does not detract from security.

Are you sure that you're actually reading the e-mails, rather than
just responding to a perceived opportunity to denigrate DNSSEC?

> It seems to me that the problem is that people recognizes it
> essentially impossible to deploy DNSSEC.

It seems to me that it is not "essentially impossible to deploy
DNSSEC".  It seems to me that there will be some effort required,
and I'm not sure that we have all the answers yet--but saying
"it's too hard" isn't the best solution to most problems in my
personal experience.

Do you believe that the postulated threats against DNS (which
DNSSEC was designed to address) are not realistic?  If so, then
that would be an...interesting...opinion to me.

  --Rip

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Jan 2004 06:51:23 +0900

Rip;

>>>>MAY be configurable as to whether to accept expired records.  If configurable,  SHOULD be
>>>>configurable to as to the maximum out of date expired records can be to be
>>>>acceptable.  And if configurable, MUST default to not accepting expired
>>>>records.

> does not lead to long-term security issues with DNSSEC.

OK.

>  However, 

The statement above says nothing about "long-term".

Regardless of whatever is the default, configuration to accept
expired records will be used widely forever.

That DNSSEC needs a lot of configuration means that, during the
configuration, administrators are tempted to change some of
the default to reduce the rest of the configuration effort.

> just responding to a perceived opportunity to denigrate DNSSEC?

You don't read the e-mails literally and assuming impractical
assumptions.

> "it's too hard" isn't the best solution to most problems in my

Introducing options means you recognize "it's too hard".

> that would be an...interesting...opinion to me.

Just before the previous meeting, I posted a solution for small
message ID space, though I don't expect you read it.

Othere threats are as realistic as DNSSEC zones with compromized
keys or DNSSEC resolvers with faked root public keys (or their
signatures).

							Masataka Ohta