[Top] [All Lists]

Re: [ietf-smtp] Endless debate on IP literals

2020-01-01 16:01:03
On 1/1/20 2:38 PM, Viktor Dukhovni wrote:

On Wed, Jan 01, 2020 at 02:08:00PM -0500, Keith Moore wrote:

In my mind the question is: how to explain to ordinary operators,
administrators, IoT device vendors, etc. how to make this work
well?    If someone is developing an IoT device that needs to send
mail, what is that device required to do, what configuration options
should it offer, etc.?
Not much.  One of (configurable per site requirements):

1. Connect to port 25 on a configured IP and send email like it's the 90s.
    The local MSA will limit access to suitable IP ranges.

Are we going to specify port 25 for pre-submission and only use 587 for "real" submission?   (and see another message about IP address authentication)

Not saying I like or dislike the idea - it strikes me that it might be the right answer but something still seems odd about it.

2. Connect to port 587, do STARTTLS and provide a configured username
    plus password to authenticate submission.  Much harder to support
    in low-end appliances, may need some managed trusted root CAs,
    NTP, ... unless OK to forgo authenticating the server in an
    isolated private network, but then see 1).

3. Same as 2, but implicit TLS over port 465.

TLS is somewhat problematic for various reasons.   For devices not connected to the public Internet, updates are harder, including updates to the list of trusted CAs (since old certs will have expired).   Also for machines that don't do DNS, TLS is still possible to use, but the client needs to know separately what name to use for certificate verification.   (Then again, last time I tried to write a HTTP client for a PIC32- only two years ago- the available TLS library didn't even have certificate verification support, in other words, it was nearly useless for security purposes.)

But I think challenge-response based on hashed passwords might be sufficient for purpose.

(For example, does it need to be able to rewrite sender addresses
containing IP address literals to make them globally meaningful while
still being distinct from one another for different sender hosts?)
A configurable origin domain would be good, the default domain suffix
from DHCP is probably a good bet if nothing better is available.  No
"rewriting", just use a sensible default.

DHCP cannot be assumed.

On many occasions I've configured an SMTP relay for several small hosts to rewrite xxx@[ip-address] to xxx(_dot_)ip-address(_at_)example(_dot_)com

If the operator of the IoT devices can say to the enterprise IT person
- I need an instance of service X, as defined by RFCYYYY, that might
make things easier and reduce the amount of gratuitous meddling that
people do with email.
Nah, most operators don't read RFCs, TL;DR.  They google some How-To
guides, maybe skim the docs of their MTA, and glance at the IoT device
settings screen and figure out what's supported on both ends, making
tweaks until it works.

Yes, but RFCs do influence how-to guides, MTA documentation and configuration settings, and IoT device setting screens.

(I realize that a lot of operators basically try random things until something seems to work.   IMO we keep making the Internet dependent on experts who know enough about the protocols to have a fair chance at getting configuration settings right even when the configuration settings aren't very well-aligned with the protocol design.   But over time those experts tend to get replaced by people who don't have the same depth and only learn some magic spells.   I don't see that as good design, though of course I admit that expecting ordinary people to read RFCs isn't workable either.)

But I also have seen occasions on which even experts trying to do the
right things, disagreed about how to do those things, in ways that
caused problems when their systems interacted.   So I'm not sure that
the standards are only for "ordinary" operators, etc.
The experts may disagree on fancy features, but the basics remain
sufficient and unchanged.

Disagree, but I'm not going to dive into that discussion.  Or maybe the "fancy features" are things that actually matter sometimes.

p.s. I somehow doubt that we should recommend authentication based only
on IP address at any level, though.  That's poor practice even for a
small network that assigns static IP addresses to all of its hosts.
Well, authentication requires credential management, ... so means for
example devices joining Kerberos domains, or manually provisioned with
passwords, ... For which the standards are much more diverse than SMTP.
If you're concerned about the complexity of configuring SMTP, then you
really don't want to contemplate securing the network.

I see a need for authenticated submission even from isolated networks, and think that both IoT devices and submission servers (or pre-submission servers) need to support some of those, and need to know which ones to support.    Some of the existing SASL methods do appear to be suitable though.

More broadly there's a widespread misconception that isolated networks
are not subject to security threats or that perimeter defenses are
sufficient to protect them, even when such networks are used to manage
critical infrastructure or equipment that can create hazards if not
properly managed.
It is not always a misconception, rather it can be a realistic
assessment that the cost of managing authentication may not be worth the
effort, and the barriers to get it working on specialized appliances are
quite high.

I would relate some shocking discussions that I've had with developers of industrial equipment, but that would be exposing their customers to even more risk than they're already assuming by using those developers' products.


p.s. I suspect ietf-smtp doesn't want to dig down into details of how IoT devices should authenticate submissions - at least not just yet - and such a topic might be better discussed in a working group that's specifically tailored to that purpose.   For now I just want people to realize that some long-held assumptions may not be universlaly valid.

ietf-smtp mailing list