Subject: Keith, Hadmut both right RE: [Asrg] Deprecating plain POP account s

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2003 04:50:18 -0800

Keith and Hadmut both have valid points. It is futile to expect Keith to
change his POP configuration. However Hadmunt is correct in stating that a
DNS name owner should have the right to be able to control the manner in
which email is sent from their zone.

I have a particular sympathy for Keith's issue since it is actually one that
affects many VeriSign (Network Solutions) customers. These customers buy a
hosted mail service with their domain name. In many cases they take their
incomming mail via the NetSol service but relay their outgoing mail through
the mail servers of their ISP. In many cases they have no choice about this
as the ISP blocks outgoing port 25.

Let us assunme for a moment that the Internet community will accept such a
disruptive change that provides no value until widely deployed. How long
would such a change take to deploy?

In an earlier message someone said changing the infrastructure would 'take
years without Microsoft and Qualcom'. I have news for folk who believe that,
it will take years WITH Microsoft, Lotus, AOL, Qualcomm and the rest.
Without it will take decades. Transition strategies are key.

The key to any authentication based approach in an environment where there
are many parties with no authentication capability at all is to have a
mechanism to exzpress and distribute the authentication policy of a
particular party.

The limitation to the RMX approach and the various lightweight
authentication mechanisms is that they only support one means of
authentication at one level of the protocol stack. It should be possible for
a zone to choose any authentication mechanism that suits their
configuration. Hedmund directs all his mail through one central server and
so can use a transport or packet layer authentication mechanism. Keith does
not send his mail through a particular mail server and so any authentication
mechanism he chose to use would have to be message based. He could use PGP
or S/MIME.

This same problem is biting us when we try to deploy IPSEC on an Internet
wide basis. Most nodes are insecure. So how do you know whether an apprently
insecure site is actually a secure site that has been the victim of a
downgrade attack.

I am currently writing a draft that proposes a generic security policy
expression mechanism for Internet protocols. This is a logical counterpart
of work that VeriSign, IBM and Microsoft have recently published that
defines security (and other) policies for Web Services.

Clearly the most appropriate mechanism for distribution of such a mechanism
is likely to be DNS. However I believe that any proposal should be generic
enough to be compatible with other bindings.

A DNS binding is likely to benefit from DNSSEC, although not if DNSSEC can't
be deployed in dotCOM and dotNET. I do not agree that securing the DNS is a
precondition for being able to make use of DNS based security policies to
secure email transport for the purposes of spam control. The widespread DNS
spoofing scenarios proposed are theoretical not practical. And if they did
prove to be practical it would merely create the currently missing
imperative for DNSSEC deployment - not a bad thing in itself.

I intend to circulate a preliminary draft before the SF IETF, I know I have
missed the cut off but I will post to the list. I believe that such a work
item could be persued as a focused WG in the IETF without waiting for this
research group to terminate since it would only be part of the solution to
spam and would address a problem more general than spam. I intend to propose
a BOF for the Vienna meeting.

		Phill

> -----Original Message-----
> From: abuse [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 2:55 AM
> To: [email-masked]
> Subject: Re: [Asrg] Deprecating plain POP accounts
> 
> 
> 
> ... somehow, the idea of 'eliminating' "POP" accounts falls short of a
> reasoned solution.  if i'm mistaken, and this a viable 
> alternative, why
> not eliminate SMTP altogether ...
> 
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Adam Back <[email-masked]>
Date: Thu, 6 Mar 2003 19:30:27 +0000

On Thu, Mar 06, 2003 at 04:50:18AM -0800, Hallam-Baker, Phillip wrote:
> The widespread DNS spoofing scenarios proposed are theoretical not
> practical. 

Probably you missed the earlier post with a pointer to a paper on DNS
attacks:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00113.html

and a description of the way that RMX proposal interacts badly to make
DNS even more vulnerable in the context of RMX.

> And if they did prove to be practical it would merely create the
> currently missing imperative for DNSSEC deployment - not a bad thing
> in itself.

However there is no upgrade path to installing DNSSEC as a way to
fixing the problem, because DNSSEC has a version rollback attack.  An
attacker can trick a DNSSEC client into thinking the DNSSEC server is
just a DNS server.  Even worse it's the same pattern of attack that
makes RMX vulnerable to DNS attacks.

To fix it you'd have to fully deploy DNSSEC and _disable_ DNS.  This
is likely a problem as hard as fixing spam, as it's of similar order
to replacing SMTP as a protocol with a cut-off date.

On top of that DNSSEC presumes a PKI, which as we've seen over the
last 5 years is a hard thing to deploy in and of itself.

Adam