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

From: "Scott Rose" <[email-masked]>
Date: Wed, 11 Feb 2004 09:48:01 -0500

----- Original Message ----- 
From: "Ted Lindgreen" <[email-masked]>

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

I do, surprisingly enough... At least enough not to resort to ad hominum
attacks.

But the CD bit is a useful bit - it returns all the security related data of
the RRset without any middleboxes performing security operations.  At least
one could determine if a RRSIG was out of date if they have the actually
RRSIG.  The CD bit (if properly implemented) is like traditional DNS - no
security.

Scott

--
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 16:38:04 +0100 (CET)

On Wed, 11 Feb 2004, Ted Lindgreen wrote:

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

The 'please-validate-expired-signature-anyway' configuration directive
changes the fundamental behaviour of the system you are analysing as well.

Roy

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 11 Feb 2004 12:37:17 -0500 (EST)

> changes the fundamental behaviour of the system you are analysing as well.

Um, no.  please-validate-... is a local directive that doesn't show up
in the queries on the wire nor affect the behavior of the upstream
servers EXCEPT to the extend that you might ask for different things.
The CD bit can trigger vastly different upstream processing (see
-protocol section 4.7), which is what Scott was suggesting (I think).

-- Sam

---

From: [email-masked]
Date: Wed, 11 Feb 2004 19:00:23 +0100 (CET)

> -protocol section 4.7), which is what Scott was suggesting (I think).

Samuel,

I did not argue that the changes in the fundamental behaviour of the
system were exactly the same. I argued that using the local directive
(flipping the boolean directive between TRUE/FALSE) changes the
fundamental behaviour of the system as well.

Concur ?

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 11 Feb 2004 14:38:03 -0500

----- Original Message ----- 
From: "Samuel Weiler" <[email-masked]>

> -protocol section 4.7), which is what Scott was suggesting (I think).

Yes, I may not have be clear enough.  Turning on the CD bit does change
processing behavior, but also helps isolate DNSSEC behavior.  Similar to
turning off DNSSEC (but not quite totally turning it off).  Having a set
default case (always rejecting out of date signatues) can be detected as a
bug using queries with the CD bit set.

Scott

---

From: Mike StJohns <[email-masked]>
Date: Thu, 12 Feb 2004 11:34:04 -0500

Religion has intruded a bit on both sides of the question.  Let me try and 
recast it a bit for further discussion.

In the certificate system, a time limited signature (e.g. validAfter, 
validBefore in a certificate) means something like "I'm willing to own up 
to the use of this certificate during this time range.  If you try and rely 
on signatures made by the owner of this certificate outside this time range 
you do so at your own risk and they might not stand up to third party 
validation".

In the DNS system, there's a question as to what we mean by the time limits 
on the signature.  If you get one (RRSIG) after its time by a substantial 
amount (e.g. 5 days) it probably means a replay, or maybe bad clock 
synchronization.  If you get one after its time by a small amount (e.g. 5 
minutes), it might mean the zone administrator is lazy, but its less likely 
that someone's trying to replay the data.   I think a time limit signature 
on the data says that "This data is valid for the time specified.  If you 
get an out of time signature, the data is no better (and no worse?) than if 
I hadn't signed it."    Given that its local policy as to whether or not to 
accept unsigned data (e.g. bogus or indeterminate), its probably also local 
policy to make this determination based on what the clock says.

Roy et al - I actually tend to agree with you, but more because I think 
there are way too many knobs here.  If I had a more security aware stub 
resolver I think the right answer is that the application decides whether 
or not it requires signed data and whether or not it accepts bogus (see my 
specific definitions in previous email), unsecure or indeterminate 
data.    In the final analysis, its the consumer who gets to decide what 
use to make of the data it receives.

All that being said - let me trot out the language I provided previously 
slightly modified:

A resolver [MAY | SHOULD NOT] be configurable as to whether to accept 
records that are invalid as to time.  If configurable,  the resolver SHOULD 
be configurable to as to the maximum out of date invalid records can be to 
be acceptable and MUST default to not accepting expired records.  If the 
resolver is not configurable it MUST NOT accept expired records.

If we use "SHOULD NOT" as opposed to "MAY" in the above, we can say " you 
can do this, but the WG generally thinks its a bad idea".    There are some 
other clauses that could be added above:

a) The resolver [SHOULD NOT | MUST NOT] accept records that are not yet 
valid (e.g. signature validity is in the future).
b) The resolver [SHOULD NOT | MUST NOT] accept records that are more than 
[1 day] expired.

My recommendations would be to use "SHOULD NOT" in the main clause, and add 
clause a) as a SHOULD NOT.

Mike

---

From: [email-masked]
Date: Thu, 12 Feb 2004 18:40:46 +0100 (CET)

Mike,

Thanks for your words, comments inline...

> policy to make this determination based on what the clock says.

There is a small difference. We've documented very clear what
unsigned/bogus/signed data is. One can base local policy on that
distinction. Accepting expired data as 'signed&valid' under terms of local
policy is not good practise, while accepting expired data as unsigned is
introducing something new. Have to think about that one.

As you said above about the certificate system, you're on your own when
trusting an expired signature that validates. That decision is fine on an
end to end system. In DNS however, the validator mostly resides on a
middlebox. Is that bad ? One thing we're attending to in the threat model
is cache poisoning. A cache is typically a module in a recursive resolver.
The same resolver where the validator might reside.

> resolver is not configurable it MUST NOT accept expired records.

You've just introduced more knobs ;-)

Anyway, I'll leave this subject for the WG to resolve. More from me will
only polarise. Meanwhile we have a deadline :-/

Regards,

Roy

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 13 Feb 2004 07:32:33 +0900

> distinction.

A problem is that "local" is not defined very clearly. Clock
accuracy is a host local issue. Required strength for
authentication is an application local issue.

							Masataka Ohta

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Feb 2004 18:36:43 -0500

-----BEGIN PGP SIGNED MESSAGE-----

{a big long thread on this, most of which I have ignored}

>>>>> "Mike" == Mike StJohns <[email-masked]> writes:
    Mike> Roy et al - I actually tend to agree with you, but more because I
    Mike> think there are way too many knobs here.  If I had a more security
    Mike> aware stub resolver I think the right answer is that the
    Mike> application decides whether or not it requires signed data and
    Mike> whether or not it accepts bogus (see my specific definitions in
    Mike> previous email), unsecure or indeterminate data.  In the final
    Mike> analysis, its the consumer who gets to decide what use to make of
    Mike> the data it receives.

  Yes, the consumer of the data is key.  
  Forget about whether or not the application knows how to make a decision.

  The application needs to be provided with the data such that it can at
least, log/audit the decision that was made.   

  *Any policy is okay*, so long as the reason for the failure is clearly 
explained. 

  This is actually more critical than the other details - if the settings
are wrong, or a resign is missed, or a replay is suspected, or whatever, then
the human system gets feedback, and something gets fixed.  Right now, we get
SERVFAIL.  

  That's why the decisions are so hard to discuss and get right.
  You can not fix this problem by more server policies. 

  Miek's document is a nice start - but the view has to start with what
information the application needs to *audit* requests which do *not* fail.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [