On Wed, 2004-10-20 at 12:01, Mark C. Langston wrote:
There's a larger problem here that I think you're beginning to touch on,
but don't quite get to: SPF moves the problem of sender nonrepudiation to
DNS space. In essence, the problem becomes DNS RR nonrepudiation.
Apropos Dan Kaminsky's recent work (which highlights problems which
have existed for quite a while; he just puts those problems to novel
nontrivial use), determining whether the RR you're using is the
actual RR becomes a bit of a problem unless you tweak your resolver
such that the mechanisms that allow such trickery are disabled.
Dan Kaminsky ROCKS. Just as you stated he's put the spotlight back onto
already known issues with DNS. Looking back to earlier this year, Paul
Watson put the spotlight back on TCP Reset attacks. Just how long will
very valid and known problems continue to go unsolved? I believe I
understand as well as anyone the underlying issues at work here, its
most certainly not an easy task to tackle. This is precisely what we're
attempting to do with SMTP whats becoming more apparent however is how
closely the one is associated with the other (DNS). Having said that, I
believe that asking ourselves questions about this relationship and its
necessity. Are they two closely intertwined? Can and should we do
something about it? Was SPF a good idea after all?
The problem is no longer cache poisoning, though that's still an issue;
the problem becomes larger, in that you've got to worry about the source
of the redirect itself, and the validity of the host to which it
redirects. You see, in DNS, one can redirect to any host without
constraint (as demonstrated by Kaminsky's work, and others). Thus,
one could simply serve what looks like an authoritative RR.
Unfortunately, I don't believe any of the existing SPF tools include
their own implementation of a resolver, and thus rely on host
configuration, and in turn the configuration of whichever nameservers
the resolver is using.
Thats a touchy subject Mark. One could easily argue the merits and
faults of doing so. Both in the interest of time, and in the interest
of both not re-inventing the wheel but also not writing more code than
is necessary (KEY point we need to establish here! Just WHAT is
necessary?) the route I took when writing libSPF was to use the present
resolver library which is almost safe to say ubiquitous across *nixes.
A lot of administrators rely on the very behaviour you have mentioned
here. In particular the existence and respect of '/etc/hosts' and
'/etc/resolv.conf'. If one opts to disregard these files it begins to
complicate things for the end-user who commonly rely either through
ignorance or through knowledge that this behaviour exists. There are
several other issues that also arise from doing this, perhaps it would
be prudent to organize a group discussion by the key players and come up
with some viable solutions.
I'll be releasing what looks to be the last release candidate before
libSPF 1.0 stable is released at which time I will be reviewing the list
of things which will be implemented in my next version. One of these
things is indeed a native and fully portable (anything with an ANSI C
library) lightweight DNS resolver library. I opted not to do this with
libSPF 1.0 because its counter-productive and even now its not perfectly
clear if such is even necessary. To be perfectly honest I spent the
time writing this resolver implementation for portability reasons far
more than any other stemming from the aforementioned recursion issue(s).
I think this approach was the best one because now I can provide support
for an existing "standard" (and I use that term lightly) through the
availability of a "feature-creep-free" library, and then approach these
now more apparent issues with a solid foundation. Those with the
competence to comprehend the ramifications of any changes can then too
also benefit by being able to run something bleeding edge with
confidence through a fall back position.
This sort of thing is a problem that limiting recursion depth won't
solve.
No it doesn't. Now that I see where this entire issue is going I think
its appropriate that some general consensus be obtained and that
implementation authors and other relevant parties in addition to all
those whose opinion and input warrant audience take part in some sort of
separate off-list (SPF-DEVEL is perfect for this) discussion and hammer
out the details of whats wanted, need, necessary and of course, actually
possible in reality :-).
Cheers,
James
--
James Couzens,
Programmer
^ ( ( (
((__)) __\|/__ __|+|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part