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
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.
(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.
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).
Agree.
> 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.)
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp