On 10/28/2024 11:19 AM, Rob Sayre wrote:
SMTP is incredibly insecure, but that's the state of play.
Rob, et al,
Something that does not attempt to be secure and, frankly, does not need
to be secure, can aptly but counter-productively referenced as
'insecure'. There's plenty of examples. Consider IP. Or TCP. Or...
In a technical discussion, use of the word 'security' in a statement of
what is or is not present, is problematic, since it isn't really a
technical term, given that it has no clear, reliable and precise
technical meaning. Say that something is secure and no one will know
what functions are or are not performed. It's an umbrella term, useful
only for very broad statements. I suppose, in that sense, your
statement actually is ok, except for its implying a failure rather than
lack of need.
TLS handles some channel security, for email, though not as much as it
could. So that's not something for SMTP. SPF does a bit of
authentication and authorization, approximately at the channel level,
given use of IP Addresses. DKIM and DMARC do some handling
authentication, but at the object level, with DMARC adding a bit of
authorization. Again, outside the purview of SMTP. And, of course,
OpenPGP and S/MIME do some authentication and confidentiality.
There really is a difference between a specification of component
behavior, versus integrated service behavior. SMTP is the former,
though as I noted, bit does make incomplete forays into the latter.
Pressing for it to make more forays into the latter is certain to
consume quite a lot of effort and time and fail to produce a truly
comprehensive result. Also it's difficult to believe that it will
produce any improvements in SMTP use.
The purpose of a -bis effort is to do incremental work. However
reviewers often take their late-stage role as doing a fresh, complete
critical analysis of every aspect of the specification, ignoring the
associated history.
The goal should be review of the new work, not the old work, absent a
clear, compelling need. And this ain't that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
