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

[Ned Freed <[e-mail]>]

Keith Moore wrote:

> 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)

I didn't think it was possible to do worse than the awful airport term
"pre-board" - which, as George Carlin noted, means to "get on before you get
on".

It seems I was wrong.

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

There's absolutely no question that SUBMIT, as presently defined is useless if
not actively inimical to a lot of IOT usage. But I don't think a precursor
step to SUBMIT is the answer, no matter what you call it. Rather, it's
a submission service with a different profile.

And I'm afraid everyone is going to have to accept authorization by IP as a
possibility, which, assertions to the contrary notwithstanding, scales just
fine to cover tens of thousands of nodes at a minimum.

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

(I have no experience with the PIC32, but FWIW the situation with the ESP32 is
better than what you describe.)

But this walks around the bigger problem, which is handling
certificate/key/password rotations and updates at scale. The tools
I've seen for this so far fail to impress.

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

The idea of using an actual PAKE does have it's attractions, although the best
hash-only mechansism are probably sufficient. But there's still the password
management problem.

> >> (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 [e-mail]

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

Exactly. This is why the business about removing support for IP literals from
"relay SMTP" worries me: It could easily lead to servers being written with the
capability removed entirely. So if you're going to do this, it needs to be done
in a separate profile document (or whatever you want to call it).

> (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.)

Very nicely put. I completely agree.

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

And flipping it around: You're not going to come up with a competent service
profile without understanding cloud security mechanisms.

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

Agreed.

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

IMO we don't have a choice if we're going to do this correctly.

				Ned