<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Note: this is not a concrete proposal just a bases for discussion.<br>
<br>
There are multiple issues here that need to be taken into account:<br>
- The publisher of the data is at fault, but the processor of the
data is blamed by the consumer.<br>
- If one processor is "liberal" and another one is "strict" the
strict one will be chastised.<br>
<br>
Background:<br>
I have talked to big ISP that does DNSSEC validation but ignores
some/all DNSSEC errors, ie returns data<br>
w/o AD bit set when there is a DNSSEC failure, the reason quoted is
to avoid bad press.<br>
Another ISP will insert negative trust anchor as soon as they detect
a DNSSEC failure and a human has checked it looks like
misconfiguration.<br>
<br>
If we want to seriously think about this then we should think of
signature stretching as a temporary<br>
negative trust anchor.<br>
<br>
If "stretching time" is going to be used it should be fair and below
are some proposals as how to do it:<br>
a) randomly select how long to stretch and change that
periodically <br>
b) during stretch do not return AD bit i.e. treat unsigned<br>
c) Add ENDS0 option (if possible) that that screams "Time
expired"<br>
d) have a way for clients to say do-not-stretch<br>
e) Also apply to inception time<br>
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.<br>
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.<br>
<br>
Speaking about a) a validator should change its stretch policy every
so often, say for the next 6 hours it <br>
will accept 6 hour stretch, then for the following 6 hours it will
accept 7 hours or follow what ever policy <br>
as long as it will not make that validator implementation better
than others.<br>
<br>
<br>
Signature stretching does not address the issue of broken DS ->
DNSKEY configurations, but it is possible to<br>
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.<br>
<br>
Olafur<br>
<br>
<br>
<br>
On 21/01/2013 15:03, Warren Kumari wrote:<br>
<span style="white-space: pre;">> <br>
> On Jan 21, 2013, at 2:55 PM, Paul Wouters
<a class="moz-txt-link-rfc2396E" href="mailto:paul@cypherpunks.ca"><paul@cypherpunks.ca></a> <br>
> wrote:<br>
> <br>
>> On Mon, 21 Jan 2013, Warren Kumari wrote:<br>
>> <br>
>>> 1: Everyone does strict implementations.<br>
>>> <br>
>>> 2: When the signature expires everyone does the
following: A: You<br>
>>> calculate by how much the zone has expired, normalize
it, then<br>
>>> multiply by 255 and call this EXPIRED-AMNT. B: You
take the <br>
>>> primary IP of your recursive server, hash it, take
the last octet<br>
>>> of the hash and call it REF-HASH. C: You hash the
label of the<br>
>>> zone apex, take the last octet and call it ZA-HASH.<br>
>>> <br>
>>> Now, if REF-HASH - ZA-HASH < EXPIRED-AMNT you can
still answer <br>
>>> the query. This means that initially only 1/255
resolvers will <br>
>>> view the zone as bogus, but as time goes by (up to
double the <br>
>>> validity interval) more and more resolvers will mark
it bad. This<br>
>>> allows for increasingly strong signals to the
operator, but <br>
>>> doesn't favor any one implementation….<br>
>>> <br>
>>> You're welcome…<br>
>> <br>
>> One wonders if this algorithm favours recursive name
servers ending<br>
>> with .8 :)<br>
> <br>
> Hmmm…. Actually, for performance reasons (hashes are slow)
I've just<br>
> tweaked the algorithm… Instead, you take the first octet, add
the <br>
> second and then subtract the sum of the third and forth. You
then use<br>
> this as a percentage of how likely you are to drop queries.…<br>
> <br>
> :-P<br>
> <br>
> W<br>
> <br>
> <br>
> <br>
>> <br>
>> The idea is actually really nice. Whether everyone
understands the<br>
>> prisoner's dilemma... I doubt it.<br>
>> <br>
>> Paul<br>
>> <br>
> </span><br>
<br>
<br>
</body>
</html>