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

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.
Keith

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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp