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

[Keith Moore <[e-mail]>]

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