[Top] [All Lists]

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

2020-01-02 22:33:49

On 1/2/20 10:30 PM, Ned Freed wrote:

Are we going to specify port 25 for pre-submission and only use 587 for
"real" submission?   (and see another message about IP address

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

It seems I was wrong.

(I always used to wonder about Dulles airport when they still used the "mobile lounges"... did you have to pre-pre-board those?)

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.

Offhand, I think I'm fine with that.

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.
I never said it didn't scale.   I said it's too easy to defeat.   Or maybe the "submission service with a different profile" needs to do some serious rate limiting to keep it from being used to inject too many messages into the system.
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.)

I haven't wrestled with one of those yet.   (On the PIC32 project I gave up after a month and put everything on an ARM-linux platform, which brought with it a completely different set of security issues of course.)

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.

My working assumption is that the larger number of IP appliances on industrial networks simply don't get updated, in any form, during their working lifetimes.    But it's hard to generalize because there are so many different industries with different ideas of standard practice.

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.


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


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

Good point.   Because of course there's a widespread expectation that I*oT devices should talk to services in the cloud.  (I hope the "must use cloud" idea is a passing fad, it leads to a lot of shortsighted decisions.)


ietf-smtp mailing list