ietf-clear
[Top] [All Lists]

[ietf-clear] "Registering" unauthorized MTAs

2004-10-13 00:48:26
From: John Leslie
Sent: Tuesday, October 12, 2004 7:40 PM


Tony Finch <dot(_at_)dotat(_dot_)at> wrote:

<...>

These include using made-up hostnames or hostnames without CSA records.

   I don't understand why that's an attack worth securing against. Simply,
the single UDP DNS query is made, and returns NXDOMAIN. There is no danger
of misinterpreting this as CSV-authorized. At worst, we're no worse off
than before CSV.

We need to be better off than before to make it useful.  Otherwise, it
appears that the protocol is geared to facilitating acceptance, which is not
a compelling problem for recipients.



   I would hope that the reputation check recommended by CSV could report
that somejunk.dotat.at is covered by a directive from dotat.at to treat
subdomains without their own CSV record as "unauthorized". That's the
second UDP DNS query (or very likely a query to a database in memory);
and the "attack" fizzles right there.

   The particular way that a reputation service finds that directive is
certainly open to discussion...

I don't think that reputation services are suitable for domain policy
statements.  There are potentially too many of them and they should have
nothing to do with the domain itself.

It is probably best for a domain to publish policy directly, and I suspect
that is what Tony is getting at with his questions.  CSV records have the
appearance of a policy statement for the domain, so they should stand alone
and be complete for the problem space they cover.  I may well misunderstand
the overall goal, so please educate me on this if I have it wrong.


<...>

So that made-up-name.cam.ac.uk or not-an-mta.cam.ac.uk don't turn up in
blacklists because they are routinely used by malware.

   I must be missing something.

   What harm is there if made-up-name.cam.ac.uk appears on a RHSBL?
You never intended it to send email in the first place. At worst, it
seems to me, it would save you the trouble of creating a SRV record
for it...

Having sub-domains show up as spew sources could affect the reputation of
the base domain.



Receiving SMTP servers would be just-plain-wrong to treat CSA as
binary accept/deny. The spec (IMHO) is quite clear that you need the
authentication of IP address, the authorization bit in the SRV record,
and a favorable reputation report in order to bypass blacklisting; and
that there's a fairly large grey area where CSV says nothing about
accept _or_ deny.

OK it isn't binary, but it does allow you to reject with certainty a
lot of obviously criminal lying.

   This is a side-effect. We shouldn't spend much time worrying about
what percentage of obviously criminal lying it catches.

In that case, I really miss the point of the protocol.  If it doesn't help
reject trivial HELO forgeries in a reliable manner, why would I, as a
recipient, want to use it?  Given a HELO name and the lack of a CSV record,
how do I know if the base domain publishes CSV records at all without doing
an expensive zone-cut algorithm?  If I know that the base domain publishes
CSV records and this sub-domain doesn't have one, I can use it as a tool to
reject.  Without that, I can't.  What am I missing?

--

Seth Goodman