IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 02 January 2020 03:36 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45C4120047 for <ietf-smtp@ietfa.amsl.com>; Wed, 1 Jan 2020 19:36:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI1S2MIsEPtg for <ietf-smtp@ietfa.amsl.com>; Wed, 1 Jan 2020 19:36:02 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4F712003E for <ietf-smtp@ietf.org>; Wed, 1 Jan 2020 19:36:01 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id F40D42A7F80; Wed, 1 Jan 2020 22:35:59 -0500 (EST)
Date: Wed, 01 Jan 2020 22:35:59 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf-smtp@ietf.org
Message-ID: <20200102033559.GQ73491@straasha.imrryr.org>
Reply-To: ietf-smtp@ietf.org
References: <20200101183846.38F7811E2E72@ary.qy> <64f30fa9-ab2a-fe48-f324-426ed48b7091@network-heretics.com> <20200101193816.GP73491@straasha.imrryr.org> <b3f0f5d9-a433-b83a-b032-b726ddd8919a@network-heretics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b3f0f5d9-a433-b83a-b032-b726ddd8919a@network-heretics.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/nfgZmw--G8IQWtrAUrwdPzUCL60>
Subject: Re: [ietf-smtp] Endless debate on IP literals
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2020 03:36:05 -0000

On Wed, Jan 01, 2020 at 05:00:45PM -0500, Keith Moore wrote:

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

No, it is just one option.  The reasons I mention 25 are:

  - It is not uncommon to have port 587 MSAs refuse submission without
    TLS, and not all low-end devices support STARTTLS.

  - Some minimally configurable appliances only support port 25, with
    configuration limited to the relay hostname or IP address.

  - On private corporate networks, the internal mailhub may well not
    offer a separate port 587 service, it just runs a port 25 MSA,
    acting a smarthost for various null-clients.

  - TLS is definitely unavoidable with 465.  Therefore, for bare-bones
    SMTP without TLS, 25 may be a safer bet.  Port 465 has only recently
    been brought back from the dead, deployment is likely comparatively
    light.

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

Just a pragmatic choice.  A device that is capable of being a TLS client
should be configurable to use 587 and/or 465, but needs to also support
25.

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

Yes, another reason why 25 is a sound minimal default.

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

Yes, that would need to be configurable, and perhaps also opportunistic
TLS without server authentication.  Which then leaves the question of
which SASL mechanisms to enable when the server connection is not
authenticated, but now we're into advanced features that I would not
expect IoT stacks to get right, unless they license a well designed
client SMTP stack.

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

Yes, and if device passwords are not also the passwords to the owner's
bank account, social media, email, ... then having it stored on the
server may be OK, but I could mention in passing that a TLS client cert
could work, even if the server is not authenticated (again advanced
feature).

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

Indeed, but it is one potential source of identity information for the
SMTP client.  Otherwise local configuration, or built-in defaults.

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

Best to work a domain name if at all possible.

> > Nah, most operators don't read RFCs, TL;DR.
> 
> Yes, but RFCs do influence how-to guides, MTA documentation and 
> configuration settings, and IoT device setting screens.

Mostly correct for MTA documentation, much less so for the how-to
guides from some random user on the Internet, and minimal designs
in low-end devices.

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

My point was that all you need is:

    * Connect
    * Wait for 2XX (possibly multi-line)
    * EHLO <client>
    * Wait for 2XX (possibly multi-line)
    * MAIL FROM:<sender>
    * Wait for 2XX (possibly multi-line)
    * RCPT TO:<recipient>
    * Wait for 2XX (possibly multi-line)
    * DATA
    * Wait for 3XX (possibly multi-line)
    * <body> (RFC5322, RFC2045, ...)
    .
    * Wait for 2XX (possibly multi-line)

which works on port 25 to a nearby suitably receptive smarthost.
Everything else is advanced features for clients that expect
more from SMTP than fire and forget submission.  Of course
things become more fun with EAI, PIPELINING, DSN, ... but
perhaps not for IIoT.

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

Operators often struggle with server-side SASL, IP ACLs are simpler and
less fragile for isolated networks.

> Some of the existing SASL methods do appear to be suitable though.

Password stores can be difficult to manage, and Cyrus SASL non-trivial
to configure.  Then you get nightmares like OAUTH...  Just "AUTH PLAIN"
is hard enough.

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

The below are reasonably simple choices.

    * IP-based ACLs
    * AUTH PLAIN
    * Self-signed TLS client cert (if the MSA supports public key
      fingerprints, obviating the need for a PKI).

All the other choices are IMHO much too advanced for the average server
operator or SMTP client implementor.

-- 
    Viktor.

v2.23.0 | Report a Bug | By Email