RE: The 'failure' of SMTP RE: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: The 'failure' of SMTP RE: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys



> From: Tony Finch [mailto:dot at dotat.at] 

> Usenet did not escape spam. Spammy usenet servers were not 
> reliably cut off - certainly the trust relationships between 
> server operators did not provide an effective way to stop 
> spam. Your last sentence above is the reason why: keeping 
> legitimate communication working is more important than the 
> inconvenience of spam.

That coupled with the difficulty of separating the legitimate communication from the spam. 

In USENET and BGP the trust relationships are only bilateral hop by hop. So I am vulnerable if anyone I connect either directly or indirectly connects to a spammer.

In other words USENET is a perimeter security model with 100,000 plus independently administered entry points. It it any wonder that it has essentially collapsed? (my ISP no longer provides NNTP as base service and this is now the norm).

There is no accountabilty.


> You can apply the same logic at the level of BGP routing: 
> there are trust relationships between networks, some of which 
> are clean and some of which are infested with criminals. The 
> latter spoil it for the rest of us but they are still not cut off.

Which is why the first step in securing BGP has to be to provide credentials that allow route advertisements to be tracked to source.

Again, there is no real accountability.


> For a third example of reluctance to punish the innocent, 
> look at the hatred directed at DNS blacklists that 
> deliberately block people who are unlucky enough to be too 
> close in network space to spammers.

The problem there was the blacklists demanded others be held accountable but refused to be held accountable themselves. They would arbitrarily blacklist sites and then refuse to unblock them. Some openly boasted of using 'collateral damage', holding innocent parties hostage as a means of creating leverage to cause an IS to comply with an arbitrary policy unliaterally set by the blacklister.

This time there was accountability but the system itself was not sustainable because the guardians of accountability were not accountable.


> Given this, your proposed architecture is just as vulnerable 
> tFrom ietf-bounces at ietf.org Wed Nov 22 13:36:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gmwwr-0003hV-Mr; Wed, 22 Nov 2006 13:35:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmwwq-0003hQ-LU
	for ietf at ietf.org; Wed, 22 Nov 2006 13:35:52 -0500
Received: from shu.cs.utk.edu ([160.36.56.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmwwp-0001Ju-3Z
	for ietf at ietf.org; Wed, 22 Nov 2006 13:35:52 -0500
Received: from localhost (localhost [127.0.0.1])
	by shu.cs.utk.edu (Postfix) with ESMTP id D72045646C;
	Wed, 22 Nov 2006 13:35:49 -0500 (EST)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from shu.cs.utk.edu ([127.0.0.1])
	by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id BxiVsZFTtKUR; Wed, 22 Nov 2006 13:35:44 -0500 (EST)
Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182])
	by shu.cs.utk.edu (Postfix) with ESMTP id 5DA935646A;
	Wed, 22 Nov 2006 13:35:43 -0500 (EST)
Message-ID: <4564987D.8030701 at cs.utk.edu>
Date: Wed, 22 Nov 2006 13:35:41 -0500
From: Keith Moore <moore at cs.utk.edu>
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: Michael Thomas <mat at cisco.com>
References: <198A730C2044DE4A96749D13E167AD37E7E72D at MOU1WNEXMB04.vcorp.ad.vrsn.com>
	<45648ED7.1050101 at cs.utk.edu> <4564932E.9090305 at cisco.com>
In-Reply-To: <4564932E.9090305 at cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: John C Klensin <john-ietf at jck.com>, ietf at ietf.org
Subject: Re: SRV records considered dubious
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

>> The point is that the distributed information store that we
>> currently know as DNS is separable from the protocol that we call
>> DNS, and we can (if we are careful) design a new protocol that will
>>  let us access that information store more flexibly while still
>> keeping the views consistent between the DNS protocol and the new
>> protocol.

> Sure, but is the trust anchor that DNS more importantly provides? On
> today's internet with all of the vested interests could the devil we
> don't know possibly be any better than the one we do?

so we shouldn't try to improve the Internet at all for fear that it
might end up being worse than what we have?

I'll offer a different point of view - the Internet is constantly being
degraded by those "vested interests" and also suffering from limitations
of its original design.  If intelligent, conscientious people aren't
continually contributing to its evolution in an open forum, the devil
that we do know will get worse and worse.

> I can imagine the only reasonable name for a working group that
> attempts that is BLACKHELICOPTERS.

random paranoia doesn't impress me.  if you have a specific threat you
want to discuss, by all means bring it up - though maybe you'd want to
wait for an actual proposal before trying to model the threats?

Keith

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.