[dns-operations] Relaxing DNSSEC rules ? Was: Re: 10% was Re: .mm ....

[Olafur Gudmundsson]

Note: this is not a concrete proposal just a bases for discussion.

There are multiple issues here that need to be taken into account:
  - The publisher of the data is at fault, but the processor of the data 
is blamed by the consumer.
  - If one processor is "liberal" and another one is "strict" the strict 
one will be chastised.

Background:
I have talked to big ISP that does DNSSEC validation but ignores 
some/all DNSSEC errors, ie returns data
w/o AD bit set when there is a DNSSEC failure, the reason quoted is to 
avoid bad press.
Another ISP will insert negative trust anchor as soon as they detect a 
DNSSEC failure and a human has checked it looks like misconfiguration.

If we want to seriously think about this then we should think of 
signature stretching as a temporary
negative trust anchor.

If "stretching time" is going to be used it should be fair and below are 
some proposals as how to do it:
     a) randomly select how long to stretch and change that periodically
     b) during stretch do not return AD bit i.e. treat unsigned
     c) Add ENDS0 option (if possible) that that screams "Time expired"
     d) have a way for clients to say do-not-stretch
     e) Also apply to inception time
     g) stretch should not be a fraction but a number of hours off 
accepted, otherwise domains that publish  long signature lifetime will 
get more slack than domains that have short signature lifetime. It is 
likely that both domains have similar reaction time to fix their DNS.
     h) Rules on min and max slack, having less than say 3 hours will 
not do any good, as reaction time + distribution time is probably longer 
than that.

Speaking about a) a validator should change its stretch policy every so 
often, say for the next 6 hours it
will accept 6 hour stretch, then for the following 6 hours it will 
accept 7 hours or follow what ever policy
as long as it will not make that validator implementation better than 
others.


Signature stretching does not address the issue of broken DS -> DNSKEY 
configurations, but it is possible to
use the signature inception time on the DS and/or DNSKEY record in the 
same way, i.e. if it looks like one has changed in the last few hours 
but the other one does not match apply similar rules as above.

     Olafur



On 21/01/2013 15:03, Warren Kumari wrote:
>
 > On Jan 21, 2013, at 2:55 PM, Paul Wouters <paul at cypherpunks.ca>
 > wrote:
 >
 >> On Mon, 21 Jan 2013, Warren Kumari wrote:
 >>
 >>> 1: Everyone does strict implementations.
 >>>
 >>> 2: When the signature expires everyone does the following: A: You
 >>> calculate by how much the zone has expired, normalize it, then
 >>> multiply by 255 and call this EXPIRED-AMNT. B: You take the
 >>> primary IP of your recursive server, hash it, take the last octet
 >>> of the hash and call it REF-HASH. C: You hash the label of the
 >>> zone apex, take the last octet and call it ZA-HASH.
 >>>
 >>> Now, if REF-HASH - ZA-HASH < EXPIRED-AMNT you can still answer
 >>> the query. This means that initially only 1/255 resolvers will
 >>> view the zone as bogus, but as time goes by (up to double the
 >>> validity interval) more and more resolvers will mark it bad. This
 >>> allows for increasingly strong signals to the operator, but
 >>> doesn't favor any one implementation….
 >>>
 >>> You're welcome…
 >>
 >> One wonders if this algorithm favours recursive name servers ending
 >> with .8 :)
 >
 > Hmmm…. Actually, for performance reasons (hashes are slow) I've just
 > tweaked the algorithm… Instead, you take the first octet, add the
 > second and then subtract the sum of the third and forth. You then use
 > this as a percentage of how likely you are to drop queries.…
 >
 > :-P
 >
 > W
 >
 >
 >
 >>
 >> The idea is actually really nice. Whether everyone understands the
 >> prisoner's dilemma... I doubt it.
 >>
 >> Paul
 >>
 >


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130121/f021d37c/attachment.html>