Re: [ietf-smtp] Characteristics of Isolated (or mostly-isolated) industrial IP Networks

[Viktor Dukhovni <[e-mail]>]

On Sun, Jan 05, 2020 at 02:38:02AM -0500, Keith Moore wrote:

> But the IIoT MSA might still be operating in an environment without
> DNS, so it can't be expected to do all of the sanity checking and
> fixup that an MSA on the public Internet would do.

The usual-suspect MSAs (at least Postfix and Exim) operate just fine in
isolated non-DNS networks.  An MSA only needs DNS when:

    * Delivering to someone else's domain on the public internet, via
      the MX records for that domain.
    * Attempting to do DANE SMTP.

neither of these apply on isolated non-DNS networks.

> I'd also like to see if there's a way to use TLS to let the connection
> be secured by a certificate on the client end, using a certificate
> issued by the device manufacturer.
>
> For SMTP, what I have in mind is a SLTTRATS SMTP extension that acts
> like STARTTLS except that the the client and server roles on the TLS
> connection are flipped - the SMTP client is the TLS server and vice
> versa.

That's possible now, using STARTTLS.  No need for a new ESMTP extension.
The client ignores the server certificate, while the server, requests a
client certificate and uses it to authenticate the client (by
certificate or public key fingerprint).

> Then the IIoT devices don't need a trusted CA list, the IIoT MSAs that
> they talk to do - but the MSAs are closer to the public network so the
> update might be easier.

They don't need a CA bundle if they are not going to authenticate the
server.  Since they can't be assumed to have a reliable clock, certs
work poorly in any case, so they could at best be (on site) configured
with a list of public key fingerprints of trusted MSAs.  In most cases
this is likely overkill.  A rogue MSA can just reject connections
blocking mail delivery, and no amount of authentication will stop that.

-- 
    Viktor.