Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago

On Jul 6, 2007, at 1:52 PM, John C Klensin wrote:

> --On Friday, 06 July, 2007 11:53 -0700 Douglas Otis
> <dotis(_at_)mail-abuse(_dot_)org> wrote:
>
> > ...
> > How will SMTP servers vet sources of inbound messages within an  
> > IPv6 environment?  Virtually every grain of sand can obtain a  
> > "new" IPv6 address.  An IPv6 address may traverse any number of  
> > translation points as well.
> > This complex topology spells the end of SMTP in its current form.   
> > Perhaps SMTP could depend upon SMTP Client names or change into a  
> > type of URI based notification process, where messages are held by  
> > an HTTP server.  The URI of the HTTP server might then replace  
> > reliance upon SMTP Client IP address reputation.  SMTP represents  
> > just one protocol heavily dependent upon IPv4.
> Doug, I think you are conflating two problems.  There is running  
> code (and extensive history) to demonstrate your conclusion is not  
> correct; the other issue may indicate that some of the things that  
> are now under development in the IETF are wrong-headed and that  
> they need to be rethought --now or later.
It is more a matter of remaining relevant.  If not now, then later  
matters even less.
> First, SMTP was designed to work in a multiple-network environment,  
> with gateways and relays patching over differences far more  
> significant than anything related to the different between  IPv4  
> and IPv6.  Sometimes it underwent smaller or larger transformations  
> in those other network-transport environments (e.g., using much  
> more batch-oriented envelope structures).  But anyone old enough to  
> have seen a message move from EARN to the Internet and possibly  
> then back to BITNET or into FidoNet or UUCP-based mail has rather  
> strong empirical evidence that a mere change of network protocols  
> doesn't do much to SMTP.   It is perhaps worth remembering that RFC  
> 821 contains a good deal of text, some appendices, and  
> miscellaneous dancing around the topic of SMTP over non-TCP services.
You are right about SMTP "working" across topologies.  I setup UUCP  
for offices back when dedicated business lines were considered too  
expensive.  I set up older messaging schemes for my customers while  
conducting a peripheral design business.  This business demanded  
timely exchanges of schematics, wire-lists, PCB photo-plots, test- 
vectors, and firmware.  When first learning of the Internet, it was  
costing more than $10 per one page fax to Japan.  It sounded as if  
the Internet was some sneaky method to "steal" expensive telco services.
Low cost Internet services together with today's level of abuse has  
lead to unintended DDoS attacks.  Defending against this unintended  
attack depends upon IP address history.  When this history proves  
ineffectively at refusing traffic from previously noted bad actors,  
SMTP no longer "works".  It has been an ongoing battle to ensure bad  
actors are unable to exploit easily obtained IP addresses.  This  
includes addresses used by dial-up accounts, compromised residential  
systems, and even ISPs not enforcing adequate AUPs.  Compromised  
residential systems makes discerning the last category difficult, and  
perhaps soon abandoned as yet another casualty of faltering security.
> On the other hand, any authentication, authorization, or validation  
> technique that depends either specifically on IPv4 addresses or on  
> some sort of end-to-end connection between the final delivery MTA  
> (or MUA after it) and Submission MTA (or earlier) is going to be in  
> a certain amount of trouble: from IPv6, from long relay chains,  
> from long-delay networks, and so on.  Obviously some of the  
> proposed mechanisms in that class are much more sensitive to  
> network variations (or, in the worst cases, any situation in which  
> there is not a single connection between the MSA and the delivery  
> server) and maybe the IETF should be looking harder at those  
> characteristics before publishing or standardizing them.
Depending upon DNS to migrate protocol behavior is one concern.   
Wildcard records in DNS can increase the amplifications of some  
"intentional" DDoS attacks.  To support SMTP, some servers will issue  
a long series of "scripted" DNS transactions which might have been  
dictated by bad actors (as if the goal was to taint and/or kill  
DNS).  At least PNRP does not depend upon DNS.  What will the IETF  
offer as an alternative to this proprietary name resolution protocol?
> But the oldest sender-authentication and message integrity  
> mechanisms of all don't depend on such endpoint connections over a  
> single network technology: I, and I imagine many others, have had  
> mailboxes on and off for 20-odd years that will not accept any  
> traffic that does not arrive with a digital signature over the  
> content that can be verified by software in the delivery  
> (receiving) system and with requirements on the signed content,  
> such as sequence numbers or time stamps, to prevent replay  
> attacks.  Such approaches either require a strong PKI or secure out- 
> of-band transmission of secret keys, don't scale, or both, but  
> those aren't SMTP problems.
An inability to validate an SMTP client name, or the remaining  
provisions permitting A record server discovery makes SMTP much  
harder to defend within complex topologies.  These are general  
weaknesses created by SMTP that are unrelated to cryptographic  
strategies.
If SMTP were used to only exchange URIs (as a public version of a  
BURL extension), then there would be no need for SMTP  
authentication.  HTTP certificates scale and are already cached by  
the OS.  Atlas, proprietary interfaces within HTTP are also nearly  
impossible to defend.  Another area where standardization has failed.
The cryptographic strategy used by DKIM does not offer a means to  
correlate signing domains with SMTP client domains transmitting to a  
public server.  An inability of domains to authorize signing domains  
eliminates what might have been a reasonable approach for coping with  
possible replay abuse.  In addition, transparent authorizations of  
signing domains using CNAMES or DNS sub-delegation makes DNS less  
robust by increasing server dependence.  Importantly, transparent  
authorization will not provide any anti-replay abuse strategy.  DKIM  
may then devolve into a key-per-user as a feckless anti-replay  
strategy.  Excessive use of short lived and large cryptographic key  
RRs may also provide another cause for DNS to falter.  Never mind the  
follow-on domain transversal or DNS wildcard policy schemes.
DNS has several weakness by today's standards, which do not lend  
themselves to easy or rapid correction.  What happens when SMTP's  
awkward defensive strategies result in a loss of confidence in a  
faltering DNS?
-Doug

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf