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

Keith Moore <moore@network-heretics.com> Wed, 01 January 2020 22:00 UTC

Return-Path: <moore@network-heretics.com>
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 D217D120020 for <ietf-smtp@ietfa.amsl.com>; Wed, 1 Jan 2020 14:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 YWup5yaKuM7W for <ietf-smtp@ietfa.amsl.com>; Wed, 1 Jan 2020 14:00:51 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FAE12000F for <ietf-smtp@ietf.org>; Wed, 1 Jan 2020 14:00:51 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4E04A218BB; Wed, 1 Jan 2020 17:00:50 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 01 Jan 2020 17:00:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+YLMGUzyuK94OYXtM4164Ftr1qPORnFv10w9OdEHB mg=; b=Rf2MJjbQCu0VJ6gRlKrHLq6x/MLHtLuqzBkyENHTcGFtZmVL+HqTvPFru wzv1QB85wZm70e1cMb3DrVG/mXjkIRvgKlWoa+TVUSKEschBNu48LyFWXUzZ2Erg R0Dzir7L34Ldj0h9INyea0bvgVvUoLP0xbh2EJMURREwBWYFyHoQ/ADXe35cyJqf vdqlcFEAW6thIsWgSZJoBWuyA802HQjKeh+4L/x1KcEVvFxBrIzk9i3PRJYFbLGU TkPEwFV9DovdhTIEJltShzX1z0kC0+z2tRPRkUtjlmS0cuw1x+jUaLJs3XXm2sTV H5FoHDt45FTdDhNFj85uccD9qDmnA==
X-ME-Sender: <xms:kRYNXvMV28bWXq-ZZXzb0rUQVaWBVLr4Eyt5C87YC8h5WJZYSr-fwQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdefledgudehhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ekredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecukfhppedutdekrddvvddurddukedtrd duheenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgv rhgvthhitghsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:kRYNXiy4vvX3kAnoCks5ryrgzERmxEzFNqpNarUublvUvGQYKlwlYg> <xmx:kRYNXvmjDYqE_SJXe7JSchejxZyzLad5lh_D-LQyFF8Zy9x9jGDWYw> <xmx:kRYNXo-L27vDWOmzQnAEgW5rTCowzFSTj0HlNnVvuaTPvvZJHJiFnw> <xmx:khYNXlfOJjJtlUVWhXM07UmnEEIwXbBWedZo9Kv2MnH7j93cF33XgA>
Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id A58EE80068; Wed, 1 Jan 2020 17:00:48 -0500 (EST)
To: ietf-smtp@ietf.org
References: <20200101183846.38F7811E2E72@ary.qy> <64f30fa9-ab2a-fe48-f324-426ed48b7091@network-heretics.com> <20200101193816.GP73491@straasha.imrryr.org>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <b3f0f5d9-a433-b83a-b032-b726ddd8919a@network-heretics.com>
Date: Wed, 01 Jan 2020 17:00:45 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20200101193816.GP73491@straasha.imrryr.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/tcs97a3nS2y-PWhowDl2Kb5PLTU>
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: Wed, 01 Jan 2020 22:00:53 -0000

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.ip-address@example.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.