[ietf-dkim] Expiration Tag (x=) is required to minimize DNSlookups.

[Steve Atkins]

On Apr 18, 2006, at 10:32 AM, Hector Santos wrote:

>
> ----- Original Message -----
> From: "Steve Atkins" <steve at blighty.com>
>
>>>
>>> But it still an optimization concept:
>>>
>>>      - No need to DNS lookup, regardless of TTL state.
>>
>> Yes. DNS is cheap, and NXDOMAIN is cached, though. How often, in
>> practice, do you think that even an MUA, let alone an MTA, will be
>> seeing a significant fraction of expired signatures?
>
> But are we ready to presume it is foregone that this will be low?   
> Low or
> high, I still don't think it substracts from the optimization  
> consideration
> based on the current semantics of the protocol.

It adds complexity. That's a cost (and given the confused semantics,
quite a significant one).

The only benefit it adds is the ability to avoid a DNS lookup in some
cases. Based on how I believe that the system will be used by senders
and recipients I think that will be an extremely rare case. <1%.

Even if it saved a DNS lookup 20% of the time I don't think it would be
a good tradeoff.

>
> What are saying anyway?  That a DNS lookup should always be done  
> anyway,
> therefore a x=tag or any other short-circuiting concept that would  
> provide
> the same optimozed result is not required?

>
> A side nit: We have no 100% reliable conclusion that all verifying  
> sites
> will have the same 100% reliable DNS operations.

The only possible design failure that could have any effect on this  
particular
case is a recursive resolver that caches results for significantly  
longer than
the TTL. (Failure to handle NXDOMAIN correctly would increase external
traffic somewhat, but, eh.)

I'm not aware of any widely deployed implementations DNS caching  
resolvers
that fail in that way.

>
>>>      - No need to do any SHA256 Hashing on a potential HUGE payload.
>>
>> If the public key has expired from DNS, then you wouldn't be
>> doing that anyway, would you? (If your MTA were ill-designed
>> enough to do that it would also be doing so for the significantly
>> larger fraction of email that has falsified DKIM headers, which would
>> seem a much bigger problem.)
>
> I think this all depends on the semantics and what time x= points  
> too in the
> cycle of key life and in combination with TTL, who know what  
> chaotic timing
> and caching issue we are dealing with.
>
> But yes, you are correct, The current semantic for making a key  
> invalid if
> when the key p= tag is empty or a NXDOMAIN and in this case, there  
> is no
> hashing overhead.  Also keep in mind that this (NXDOMAIN) means  
> with Section
> 6.2 Step 2.
>
>>> This is clearly an optimization any good engineer will see.
>>
>> I don't really care one way or the other, but describing this
>> feature as "clearly an optimization" seems to overstate the case.
>
> Probably. But it also depends on what a verifier is experiencing  
> and I am
> for using our insights to make this an efficient system without  
> changing the
> end results.   The concept is clearly an optimization because the  
> results
> are not changed.  It is clear step to removing any additional  
> processing or
> consideration required.
>
> I am not disagreeing that it net effect is major. By no means, but  
> if you
> don't have to do an DNS lookup, and the specs has an implicit  
> semantics to
> this effort, and the end results are the same whether you do or  
> not, then
> why enforce it?

It makes the signature header bigger. That's mildly bad, and in the  
common
case (bulk mail) the increase in payload size will outweigh the DNS  
traffic,
so any argument based on reduction of network traffic is not convincing.

The network traffic issue means hat the really large mailers will  
likely not
use the feature (why do you think they use domain names like m0.net?).
That means recipients will not see it on the vast majority of their  
bulk mail
load.

It adds complexity to the validator, and simpler is always better  
than more
complex, both in terms of having people write code, having them agree
on standards and deploying systems.

Unless I'm misunderstanding something it adds a clock-skew vulnerability
which wasn't previously there.

It's also a rat hole under a bike shed.

If the x= tag only value is the ability to occasionally avoid DNS  
lookups
(as opposed to it having some other semantic value) then the additional
complexity doesn't seem worth it.

I've not chimed in before because I really, really don't care. It's  
clearly
a misfeature in the protocol, but arguing about it for a month and
delaying the eventual draft by at least that long is far, far more  
damaging
than adding one extra piece of unneeded chrome.

Simple, functional and deployed beats complex, over-designed and
theoretical.

Cheers,
   Steve