Re: DNS matters & Wildcards

At 05:30 PM 5/6/2005 -0700, william(at)elan.net wrote:
> On Fri, 6 May 2005, David MacQuigg wrote:
>
> > Alan,  I appreciate your comments, and apologize for my rash statements.
> > The Subject line was intended to be humorous, not rude.
> Thank you for explaining that. In that case you would not mind that I cut
> subject a bit - as a user of wildcards it was kind of insulting.
Again, sorry for the misplaced humor.  Having just read the IAB document, 
and being rather astonished at some of the problems with wildcards, I was 
thinking - make the recommendation against using wildcards with SPF a 
little stronger, but not a prohibition.  That's a "downgrade" in stock 
analyst lingo.  I should know better, having worked many years via email 
with non-native English speakers.  Humor is almost always misunderstood, 
because it is tied to a specific culture, or the idiosyncrasies of a 
particular language.

> > The problem is not that 1 in 1000 chance that an email goes to an 
> > incorrectly typed, but valid address.  The problem is 1000 times worse, 
> > because *any* misspelled address will go to the wildcard MX.
> You're still angry from when Verisign tried to put wildcard in .com/.net 
> zones - that is not exactly correct use of wildcards. You have to be 
> careful what you use them for and how and make certain that administrator
> of parent domain has full right to make decisions for ANY child subdomains
> (no matter wildcarded or not).
.com has the technical *ability*, not the legal *right* to capture email to 
me(_at_)mycompany(_dot_)com(_dot_)  At least that's my understanding of US law.  Someone 
tell me if that's wrong.

> > Wildcards aren't incompatible with SPF, they just make SPF more 
> > complicated and prone to error.  The other methods (CSV and DomainKeys) 
> > actually are incompatible, because they use the _namehack.
> That statement is not correct. Neither CSV nor DK any more or less 
> incompatible with DNS. And it would also be true that use of _namehack
> does not make problem of wildcards any bigger or smaller then what
> it is with SPF. I had a long post on this subject during MARID already,
> don't have time to search archives, perhaps somebody else can.
As I understand it, a domain name like _client._smtp.*.mydomain.com is 
illegal in a zone file.  This is what you would have to do to make CSV 
records apply to any name under mydomain.com.  That's what I meant when I 
said wildcards were incompatible with CSV.  Same for DomainKeys.  SPF 
avoids the problem by putting its records under mydomain.com.  Then 
*.mydomain.com is legal, and a query for SPF records on any name under 
mydomain.com should work.
Please insert AFAIK in front of every sentence above.  I'm not pretending 
to be an expert.  Just being brief.  Corrections are welcome.
It seems significant to me that both CSV and DomainKeys are not worried 
about using _namehacks.

> Don't be in such a hurry to post about subject unless you're already
> well familiar with it to be able to do it. This will save you from 
> unnecessary flames....
Then I will never learn anything.  One hour of the right kind of discussion 
is worth ten hours of reading a book.  Flames don't bother me, except that 
they very quickly make discussions unproductive.

> > DNS has worked remarkably well, and it really is the best way to provide 
> > an email authentication service.
> I'm curious what you base such a statement on? Its not all clear to me
> even though I've a have done considerable research on the subject by now.
I assume you are objecting to the second statement.  Again, I'm not an 
expert in DNS, but I can't imagine a more efficient way to provide a packet 
of information about any domain on the planet.  UDP instead of TCP.  Record 
caching.  Redundancy.  Mature technology, already deployed.  What more 
could we ask for?  I guess a hidden assumption here is that we really don't 
need 100 packets at each hop.  If that were a fundamental requirement of 
email authentication, then I could see considering some alternative to 
DNS.  DNS would still probably win, however.  We would simply put the 
authentication records on separate servers, so any loads from email 
authentication don't affect the rest of the Internet.  _AUTH.mydomain.com.mail.

> > I'm very surprised when I see apathy among the "DNS folks".  Instead of 
> > just shooting SPF down, why don't they jump in and say "Great idea. Now 
> > if you just change this and that ...".  I guess from their point of view, 
> > the "SPF folks" aren't listening.
> In their perspective the statement you made above (about dns being best
> way for email authentication) may not be correct, nor is SPF design.
>
> There are very very smart people involved with dns design who know the
> subject of multi-network distributed dns database with multiple trust
> boundaries and how to keep such system stable rather well, so don't just
> dismiss what they say.
Saying some of them seem apathetic is not dismissing what they say.  I 
understand their objection to SPF.  I'm just disappointed to see no 
alternative proposal.  DNS is the key to the solution.  The DNS folks 
should have jumped on this long ago.

> And I happen to agree with them somewhat because SPF seems to have been
> put together out of plaster of multiple pieces in a way as to make it
> most convenient and most marketable to users. This is not necessarily the 
> best way to create a security infrastructure, in fact if you look at 
> Microsoft which often has used same principles with their extensions
> and programming in Windows, you'll see that such marketing and 
> user-convenience principles can later lead to wide-ranging security 
> implications and that can become a problem that is very hard to manage 
> when such design is widely used by everyone and then the problem can 
> effect 100s of millions of internet users and take long time to fix.
> The question really is if they are overestimating the problems in spf1 too 
> much or not (they probably are - dns designers are extremely cautious).
If there is a one-in-ten chance that what they worry about will happen, we 
should fix it.  Radu has a possible solution with his "mask" 
proposal.  I've put that into a "Quick Reject" method QR1 which could run 
independent of SPF.  For that 1 in 100 piece of spam where the QR1 result 
is NEUTRAL, and if there is time, then do the full SPF check.

> > The proposal I'm working on will be (SPF3 I hope) the ultimate efficient 
> > use of DNS for email authentication.  One query to a known  server, and 
> > bingo, you get everything you need for authentication and domain-rating 
> > for all the mail servers in an entire domain. Zero worry of DNS 
> > loading.  This is not a difficult technical problem.  I believe A DNS 
> > expert could write this proposal much better than I can.  Why aren't they 
> > motivated?
> I'll provide smaller proposal that can satisfy folks who want pki
> records with spf within next couple months, it may satisfy some who
> want it (even if I do not necessarily agree with this apprach, this
> would make some things and some lookup easier and faster).
>
> As far as widerange redesign for spf3, the reason we are not working on
> it is because spf community still has not recovered from political chaos
> caused by SID and MARID and SPF Council has been slow dealing with that
> and finalizing push of spf1 through ietf. They have not provided directions
> and there is yet no opportunity for open discussions for future spf 
> version design yet. I was personally hoping we could get started on 
> Unified SPF and spf version x (x>1) from this february if not earlier.
You gotta understand how bad this sounds to the non-techie politicians and 
lawyers at the FTC who are ready to kick butt.  I just hope their next 
solution isn't as ineffective as CAN-SPAM.  I'm hoping to get them focused 
an a simple neutral "standard" that will not require changing everything in 
SPF, but will allow the industry to move forward, even while we diddle with 
the details.

> Without going into details, I can already tell you that almost certainly 
> your current proposal will probably never be accepted for spfX. This does 
> not mean its bad for you to propose it and in doing so it should cause you 
> to do more research more on the subject and then you would be better 
> prepared for constructive dialog and design that will really be necessary 
> for SPFx. Note that work in this area will have to satisfy multiple 
> parties here that will have to participate in such a design.
A compromise standard will be hated by all sides.  The question will be, 
however, Can you live with it?  To shoot it down, an advocate will have to 
prove to a panel of neutral experts that it really does break their 
method.  This will be difficult, because the standard will be simple, and 
it will be hard to come up with mind-boggling arguments against it.

> > I still wish someone could explain the fundamental benefits of wildcards. 
> > The best I have so far is that some admins feel a need to "hide" the 
> > names of their MX hosts from the outside world.  Does that help avoid a 
> > DoS attack or something?  I'm still talking with the DNS expert offline.
> This is not a right place to ask about it. DNS lists, like bind-users or 
> dnsop are. As I told you various people use it for various staff and its 
> not all the same.
I'll drop it for now.  I've got enough info to move forward.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *