ietf-dkim
[Top] [All Lists]

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

2006-04-18 11:01:57

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


----- Original Message -----
From: "Steve Atkins" <steve(_at_)blighty(_dot_)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


_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html