Re: Microsoft takes over British Telecom

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: <[email protected]> 220 OK RCPT TO: <[email protected]> 220
>  OK RCPT TO:<[email protected]> 220 OK ENVSIGN: <PKI signature of
>  [email protected][email protected][email protected]> 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