Subject: Re: Faux wildcards

From: Peter Koch <[email-masked]>
Date: Sun, 16 Jan 2005 01:16:55 +0100

"John R Levine" <[email-masked]> wrote:

> For CSV we're using repurposed SRV records.  They have the fields we need,

you're not really *using* SRVs in what was draft-ietf-marid-csv-csa-01.txt,
they are just used as containers for your data with e.g. the weight field
redifined or 'overloaded'.

> useful.  One is forgery.  I have domains that contain no MTAs, and it

Same problem hare as with the recent SPF thread: RRsets are associated with
domain names, not with what is perceived as 'a domain', i.e. everything
down the tree starting usually at the second level. For the latter you'd need
wildcards (still with a conceptual difference).

> HELO's as <anything>.services.net is lying.  The other is what I

How about the absence of the RR as an indicator?

> generically call Big ISPs, with a large farm of hosts, such as dialup or
> DHCP users, all of which exist and have names, but by policy none of which
> should be sending mail directly.  Although in theory it would be possible
> to add a SRV record to correspond to each A record, it would aid CSV's

You mean an SRV RR at each domain name that owns an address (maybe A) RR?
Why don't you just specify that? The number of names is just a provisioning
problem.

> adoption if they could say in one place that all of their authorized mai
> client hosts have explicit records and the rest are no good.

But that's not how the DNS works. Why would one willing to adopt CSV or
anything similar not be able or willing to add the necessary RRs below
the zone apex?

> We went throught the usual supects.  Wildcards are out because they don't
> work with prefixes, and if we got rid of the prefixes, we'd have other

They work perfectly well, but they just either cover more than you need or
in case the owners exist (i.e. hosts have A RRs) the wildcards do no longer
apply.

> with the same arguments we've recently heard here.  So we ended up with a
> tree walk, not unlike the one that was proposed for WHOIS last year.

As I said in an earlier message, the _whois._tcp thing also walks the tree,
but that's something completely different because it follows the DNS hierarchy
and does not imply or deduce any (policy) information further up or down the
tree.

> 	_client._smtp.EXAMPLE.COM
> 	_client._smtp.COM
> 	_client._smtp.

Again, RFC 1535 says "don't".

> domain puts a record high up in the tree, it'll be found quickly, and if a
> bad guy does a fake HELO x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.example, the walk
> can if it wants decide that since nobody's ever seen a real HELO with more

And why would you know that a CSV RR published in the e.g. Uni-Bielefeld.DE
zone would apply to anything in TechFak.Uni-Bielefeld.DE or Biologie.
Uni-Bielefeld.DE or anywhere else, regardless of any zone cuts in between?

> We should add a stop rule saying that you don't walk above the first or
> second level of the DNS tree to limit the number of visits to the roots,

Or to "co.TLD", for example? (Anyone propose TLD based exception or rules
lists (UK:2, DE:1, MUSEUM:0)?)

> If you accept our premise that some sort way to announce the CSV policy
> for a subtree of DNS is useful, is this the best we can do?

Ex falso quodlibet. Following draft-iab-dns-choices-00 and what you've
described a dedicated RR type (your overloading of the SRV seems almost
no better or worse than using a TXT to me) is the preferred choice.

-Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Pekka Savola <[email-masked]>
Date: Sun, 16 Jan 2005 08:03:03 +0200 (EET)

On Sun, 15 Jan 2005, John R Levine wrote:
> I've been working on CSV, a simple scheme for HELO/EHLO authentication
> with Dave Crocker and some other people.  By far the knottiest question
> we've been wresting with is if and how to do wildcard-like things.
>
> they're widely supported by DNS software, including software written in
> the Seattle suburbs, and the name prefixes that all SRV records have avoid
> collisions.
[...]

If you want to do wildcard-like thing, maybe wildcards is the answer, 
but not necessarily in the place you were thinking of using them..

I don't think this answers your actual question, but people have 
deployed a mechanism where information is stored in the reverse DNS; 
you'd create explicit records for the valid IP addresses of mail 
servers, and use wildcards to cover the rest with "don't accept mail 
from here" records.

And if the record for mail servers was actually specified to be a 
pointer to the forward DNS, that could also provide a means to give 
information what the EHLO string should be, e.g.,

*.3.4.in-addr.arpa. MAIL-EHLO [some encoding to say "nope."] 
1.2.3.4.in-addr.arpa. MAIL-EHLO good.example.com.

then if you wanted to "verify" (though I'm not sure what this would 
actually verify..), you could do a second lookup for:

_client._smtp.good.example.com. which would have to point at 4.3.2.1

This avoids having to walk down or up the tree. Take a look at: 
draft-durand-naptr-service-discovery-00.txt

I don't quite understand why you'd want to look up EHLO string, 
instead of getting the information from the IP address; an attacker 
can make EHLO arbitrary and make all kinds of attacks, but IP address 
has a fixed format is hopefully (in this kind of TCP session) 
difficult to spoof.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "John R Levine" <[email-masked]>
Date: 16 Jan 2005 01:28:04 -0500

> servers, and use wildcards to cover the rest with "don't accept mail

That's MTA MARK.  I've seen the spec, but I don't know of anyone who uses
it.  It's an OK design, except of course that it suffers from the usual
problem that wildcards don't do what you want them to.  In this case
wildcards are useless since any name with a PTR RR, which should be all of
them, won't be covered by a wildcard.  I've seen variant versions that
stick in extra levels of name to move the mark records into a separate
sub-namespace, but I think the deployment issues (see below) make that
doubly impractical.

> instead of getting the information from the IP address;

Because rDNS is a mess.  There are enough situations where the people in
charge of the rDNS for a chunk of IP space don't talk to the people using
that space that I don't know anyone who thinks it's practical to put
anything other than PTR records in rDNS space.  We deliberately decided to
key CSV from the HELO name rather than IP because it's much more
reasonable assume that someone sending mail for example.com controls the
DNS for example.com than that they control the rDNS for their servers.

You don't have to tell me that's not how it should be, but that's how it
is.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: wayne <[email-masked]>
Date: Sun, 16 Jan 2005 12:00:01 -0600

> we've been wresting with is if and how to do wildcard-like things.

Disclamer:

SPF and CSV are (arguably) competing proposals.  Both are designed to
help reduce abuses in email.  Both cover, in part, the HELO domain.
SPF abuses the TXT RR, CSV abuses the SRV RR.  CSV requires fewer DNS
lookups, SPF has *far* more deployment.  Both run into similar
problems.

For the purposes of namedroppers, I think it would be best to avoid
any discussions about which is "better" and to discount comments from
backers of one proposal that disparage the other.  (I'm an SPFer.)

> GOOD.EXAMPLE.COM, the server looks up
>
> 	_client._smtp.GOOD.EXAMPLE.COM
>
> and if it finds it, [...]
>
> But if the SRV record doesn't exist, then what?

This gets back to what I posted yesterday:

| The real-world problem that we are trying to solve is:
| 
|     Domain owners want to have a voice in how the domain name that
|     they have bought gets used.  Others would like to hear what the
|     domain owners have to say. The particular case we are dealing with
|     is email in conjunction with SPF, but there are other cases too.

Ok, John is talking about email in conjunction with CSV, but there are
also many other similar cases in conjunction with email.  For example
Yahoo's DomainKey's proposal and the Identified Internet Mail (IIM)
proposal both could really use similar functionality.  It would be
nice if there was a way of saying "all email from my domain is S/MIME
(or PGP) signed, and here is the cert".

For non-email items, things like the RP RR would be *far* more useful
if it could be wildcarded to the entire domain/zone.

> [snip]

Most of the rest of John's post follows *very* similar discussions in
the SPF community, only we weighed the costs slightly differently, and
came to the conclusion that finding the zone cut was slightly less
ugly than a tree walk.  I can't speak for the
CSV/DK/IIM/etc. communities, but I think the SPF community would jump
at a better solution than either zone cuts or tree walks to solve this
problem.

The pressure for a solution to the this real-world problem is huge,
especially in the anti-phishing community where.  For example,
citibank, ebay and earthlink all want to be able to assert claims over
all of *.citibank.com, *.ebay.com and *.earthlink.com, not just the
points that exist.

-wayne

---

From: wayne <[email-masked]>
Date: Sun, 16 Jan 2005 12:11:38 -0600

> DNS for example.com than that they control the rDNS for their servers.

I'll add two more reasons for not using the IP address and using a
domain name instead.

First, the folks running the in-addr tree have said "DON'T!  We can't
deal with the extra traffic."

Secondly, the domain names show up in email headers, such as the
Received: header.  Experience has shown that there is a very large
number of people who know enough to get their mail agents to show the
headers, and yet can not actually read and detect forgeries in them.
As a result, just having your domain name show up near the top of the
Received: headers can result in a lot of people incorrectly assuming
your domain is somehow responsible.

-wayne

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Jan 2005 22:30:26 -0500

>deal with the extra traffic."

If the in-addr tree folks can't handle the traffic now they need additional
resources. If this is so important to citibank, ebay, etc. they can easily
afford to shell out some money to help out the in-addr tree folks with
additional infrastructure.  The root operators are doing it, it's just
another branch of the tree.

>your domain is somehow responsible.

I have no idea what that means and why you think that not using the IP
address solves this. If the mail gets sent, whatever is there is still there
unless you are thinking of rewriting the headers along with way.

Danny

---

From: Robert Elz <[email-masked]>
Date: Mon, 17 Jan 2005 14:31:16 +0700

Date:        Sun, 16 Jan 2005 12:00:01 -0600
    From:        wayne <[email-masked]>
    Message-ID:  <[email-masked]>

  | The pressure for a solution to the this real-world problem is huge,

Of course.  And this is really the problem.

  | especially in the anti-phishing community where.  For example,
  | citibank, ebay and earthlink all want to be able to assert claims over
  | all of *.citibank.com, *.ebay.com and *.earthlink.com, not just the
  | points that exist.

And of course, they want the same kind of protection in other environments.

ebay is almost completely electronic (I believe) so it is hard to use as
an example, and I must confess my ignorance, I don't know what earthlink is.

But citibank is a great example.   Not only would they like to stop people
using *.citibank.com for unapproved purposes, they also want to stop people
setting up buildings on random street corners, with a sign saying "citibank"
and proceeding to accept deposits...   But do they do that by demanding that
the makers of paint generate paint that won't form into the word "citibank"
unless it has been passed through an approved citibank wharehouse?
Hardly - they don't use anything related to the technology of sign making
at all to get the protection they need.

Just the same way, they desire (I presume) to stop unauthorised persons from
sending letters saying "Your citibank credit card account is overdue, please
remit $37.18 to in the enclosed reply paid envelope within 7 days".  Do they
do that by having printers refuse to write the word "citibank" (or the logo)?
Or by having the post office only accept mail with a citibank (style) of
logo on the envelope if it is posted at a particular post office (and then
validate each message as it is posted).   Again, don't be absurd.

The problem here is that there is this immense pressure to have the
problem "fixed", and rather than being honest, and simply replying "we can't
reasonably fix that from where we are, look elsewhere", most of the
community is out there saying "sure, we're technologists, we can do anything"
and promising that a fix will be found.    And then, of course, because
we are technologists, and for that matter, network protocol workers, that's
the one tool that we have to manipulate - so that's what people (with all
of the best intentions in most cases) are out there doing - trying to use
the only tool at their disposal to fix a problem they've been told that
they have to fix.

The more responsible attitude however would simply be to say "no, sorry,
we cannot fix this problem, look elsewhere for a solution", because that's
really the truth.

kre

ps: now having typed all this, I realise that it is totallu inappropriate
for namedroppers, so I better make sure I find the "erase" button before
I accidentally push "send" and awa

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 17 Jan 2005 10:26:39 +0100

<chair-hat off>

On Sun, 16 Jan 2005 12:11:38 -0600

>  deal with the extra traffic."

Interesting, I wonder who claimed that they run the in-addr tree?  I
wonder for which zones these folk run authoritative servers.

-- Olaf 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: wayne <[email-masked]>
Date: Mon, 17 Jan 2005 09:37:14 -0600

> wonder for which zones these folk run authoritative servers.

Short answer:  I was wrong.  Sorry for the confusion.  The rest of the
problems with dealing with only IP addresses remain.

Long answer:

I have never really been involved in any of the proposals that put
stuff in the in-addr tree and did not follow the discussions closely.
Either my memory is bad (probable) or I can't quickly find any quotes
to back up my memory.

I seem to recall several people at the IETF-59 MARID BoF expressing
concern about the DNS loads, in particular in the in-addr part of the
tree.  The video of the BoF is still around and I can dig through it
if people *really* care.

Easier quotes to find come from the MARID archive, such as:

http://www.imc.org/ietf-mxcomp/mail-archive/msg00135.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg02530.html

These posts express "concern", "wanting to be kept informed", "will
need time to upgrade", etc.

-wayne

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Jan 2005 11:00:22 -0500

>http://www.imc.org/ietf-mxcomp/mail-archive/msg02530.html

Ack - I'd change the tone to "BEWARE!  We may have to scale."  The 
bigger issue is *voluntary* participation in the reverse map and 
lackadaisical maintenance of the delegated servers.  Policies would 
need to change, a non-technical problem, to solve that.

What ever happened to that 'reverse map is required' draftin DNSOP? 
;)  I ask quasi-rhetorically.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: Robert Elz <[email-masked]>
Date: Tue, 18 Jan 2005 06:35:02 +0700

Date:        Mon, 17 Jan 2005 11:00:22 -0500
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06110402be118f54d6b0@[10.31.32.134]>

  | What ever happened to that 'reverse map is required' draftin DNSOP? 
  | ;)  I ask quasi-rhetorically.

One might hope it is dead.   There's no rational reason to require that
(as opposed to permit it) - aside for making more work for DNS operators.

We have evidence that the net works without in-addr.arpa mappings, that's
what half the world is doing today.   Clearly they're not essential.

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Jan 2005 07:58:25 +0200 (EET)

> what half the world is doing today.   Clearly they're not essential.

This should be brought up in dnsop -- but there have been efforts to 
revive it.  Not as a document describing "do reverse mapping, period", 
but as a document describing why it's a good (or bad) idea.