--On Friday, 24 October, 2008 16:17 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
...
RFC 3207 is extremely weak from the security point of view.
For example, it says "The additional option of using TLS when
possible SHOULD also be provided." This option makes most MUAs
vulnerable to man-in-the-middle attacks in common
configurations. The RFC suggests a mechanism to mitigate this
weakness - "An implementation MAY provide the ability to
...
Tony,
I'm going to pretend that I don't have an opinion on the
validity of your comments. Let's just suppose that you are
correct and that some sufficient fraction of the community would
agree with you after, if necessary, some education and
persuasion. There would then, IMO, be three choices:
(1) Move to deprecate the thing, presumably making it historic
(or using the long-forgotten recommendation levels to identify
it as NOT RECOMMENDED), on the theory that it is worse than
nothing.
(2) Fix it, on the theory that the idea of using SMTP over TLS
is reasonable but that the specification needs tightening up.
(3) Just ignore the issues and pretend that they don't exist.
I think the third is untenable if we believe our standards
should be credible, even if it is the default.
The second is completely consistent with generating a new
document and trying to advance it to Draft Standard. If that
were to fail because of the number and nature of changes that
would be required, we would still have a document to recycle at
Proposed that, presumably, would be better than what we have
now, especially given the weaknesses you identify/claim.
Are you suggesting some other course of action?
john
p.s. While others may have other reasons, this sort of thing is
exactly why I believe that we should put some effort into taking
the email documents that have been sitting around for some time
and that have an important role in the infrastructure, reviewing
them, and advancing them on the standards track. Doing so isn't
just symbolic. It gives us both the opportunity and obligation
to review which requirements have turned out to be too weak or
too strong, what is ambiguous, and what people either haven't
implemented or cared about in practice ... and to fix things as
needed. Too many of our Proposed Standards are a little too
close to what might be described as "compile and ship" from an
implementer standpoint. That is fine for Proposed Standards,
but they shouldn't be the last word on the subject.
Personally, I think Paul did a rather nice job with 2487/3207
given what we knew, what experience we had, and what we could
say with certainty at the time. But it has been enough years
that, IMO, some updating and clarification is in order. And
this certainly is not the only spec in that state.
john