On 10/28/11 6:38 PM, Paul Smith wrote:
On 28/10/2011 19:28, Douglas Otis wrote:
> There are many methods that might be used to authenticate outbound
> MTAs, such as SMTP Auth. Ideally SMTP would include DANE
> extensions used in conjunction with Kerberos. If it were not for
> DKIM ignoring prepended headers, it would have merit as an
> anti-phishing strategy. Since DKIM does not verify who sent what
> to whom, it can only identify domains considered "too big to block"
> as well.
Excuse me for being thick, I'm trying to understand your thoughts.
I can sort of see how you could AUTHENTICATE outbound MTAs, however
that's not the problem as far as I can see. You can reliably
authenticate an outbound MTA based on its IP address at the moment
(although that would probably be less useful than authenticating a
'group' of MTAs based on the owner, eg Yahoo, and will be less useful
with IPv6). Some of the technicalities of authentication based on
cryptographic means are a bit unclear, but I can see that it could
probably be made to work.
However, once you have authenticated the MTA, you then need to decide
whether to authorise it,and what to authorise it for. Are you talking
about just authorising it to be able to send mail from a particular
domain? (If so, I'm not sure how this fixes the 'forwarding
problem'), or authorising it be able to send mail to me at all? (in
which case, who would decide on that authorisation?)
David Black and myself authored a draft describing a method to authorize
any number of domains using a single small DNS transaction. Murray also
authored a similar version once this draft expired. Attempting to
publish entire IP address sets for email domains is highly problematic,
especially when misapplied as a basis for assessing accountability.
Use of IP address authorization based upon entire address sets will
become highly disruptive from either a DDoS or rejection basis. IP
address translations occurring at providers that can not be anticipated
by senders. Any expectation that possible LSNs will be white-listed
would permit any amount of abuse.
(AFAICS Something like SRS should probably be able to fix the
forwarding problem if the rest of the system is setup correctly)
Rather than expecting recipients to sort emails based upon message
elements not authenticated with those who issued a message to specific
recipients (which DKIM does not do), a more effective scheme holds
outbound MTAs accountable for mitigating abuse. MTAs failing to respond
would be blocked. Requiring outbound MTA to respond better informs
individuals when accounts or systems are compromised and is the most
effective method for controlling abuse.
You say "Ideally SMTP would include DANE extensions used in
conjunction with Kerberos" - now, I'm not very familiar with DANE or
Kerberos at the moment, but I think DANE lets you associate a
certificate with a domain name using DNS - yes?. Since it wouldn't be
possible for a sending MTA to authenticate using such a certificate
based on the sender's email domain, I presume you mean it will use
the certificate based on the MTA's reverse DNS entry? So, how would
that link the sending MTA with the sender's email address?
Some delivery issues occur when recipients are unaware their servers
lack adequate resources where connections fail and yet these failure are
not logged. Doing any type of cryptographic authentication adds
overhead, where a hybrid Kerberos/SMTP approach provides an efficient
method with increased control. Those wanting to obtain fast processing
would first authenticate with a designated Kerberos server located by
SRV records. Once authenticated, a data-structure (perhaps published
using APL RFC2133) could be accepted to open firewalls at the receivers,
where individual SMTP transactions first exchange long-lived easy to
process Kerberos tickets.
And would Kerberos need a separate server? If so, where would that
be, the sending or receiving end? (I'm not sure I like the idea of
having to use Kerberos)
If you own a Mac, Apple provides users Kerberos services to enhance
security on otherwise insecure networks. Any large domain could offer
their own Kerberos server where senders would obtain a ticket once every
10 hours for example. It is also likely Kerberos services will be
offered by various third-parties as well.
If you are just going to authenticate based on the MTA's reverse DNS,
then why not just mandate TLS and authenticate the client certificate
using DANE?
rDNS is highly problematic because this involves separate
administrations. Those running a service are not necessarily delegated
to publish rDNS records. With the IP address ranges permitted by IPv6,
rDNS is also unlikely to be useful for differentiating different
categories of IP addresses. It is not practical to expect SMTP to query
rDNS against every IPv6 connection. It is also not practical to expect
a third-party will be publishing this information either.
Could you not change SMTP to go something like: EHLO sender 220
ENVSIGN CHALLENGE=RandomText
MAIL FROM: <sender(_at_)domain(_dot_)com> 220 OK RCPT TO:
<rcpt1(_at_)user(_dot_)com> 220
OK RCPT TO:<rcpt2(_at_)user2(_dot_)com> 220 OK ENVSIGN: <PKI signature of
RandomText+sender(_at_)domain(_dot_)com+rcpt1(_at_)user(_dot_)com+rcpt2(_at_)user2(_dot_)com>
220 OK
The sender signs the envelope data using the private key; the public
key is exposed using DNS or something (DANE?) . Kerberus isn't
needed, and the sending MTA can send from multiple different domains
in a single session.
Kerberos was suggested as a way to avoid much of the overhead related
with processing certificates at each exchange. It also provides a way
to offer layered protections, such as selectively enabling firewall
subsequent to completion of a Kerberos exchange. Kerberos exchanges
would be at much much lower rates than that demanded by SMTP.
(Still doesn't solve forwarding without return path rewriting, or the
general authorisation problem, but authenticates the sender MTA
effectively, AFAICS)
IMHO, the IP address authorization scheme was poorly considered. With
more than 95% of SMTP transactions being abusive, expecting recipients
to then perform as many as 100 additional SPF DNS transactions and any
number of reputation transactions per message is neither practical nor
safe. In the face of IPv6, any IP address authorization requirement
will also be highly disruptive.
There is a practical way for each domain to authorize other domains.
Whether this would be needed after outbound MTAs have been held
accountable is yet to be determined.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg