On Jul 6, 2007, at 1:52 PM, John C Klensin wrote:
--On Friday, 06 July, 2007 11:53 -0700 Douglas Otis
<dotis@xxxxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf