The environment has changed a great deal. I don't know why people
thought MITM attacks weren't feasible in 1996 -- Joncheray published a
paper on how to carry them out in 1995 -- but they're now trivial.
There are some meta-problems with this thread.
(Aside: John K has raised his own perspective on some of them and I'd
like to try to raise mine. I don't see them as conflicting with John's,
but rather I'd like to treat them as separate just to avoid having to
worry about synchronization. If they overlap with his, fine. If not,
well, that's fine too.)
This draft BCP touts some basic practices to improve the accountability
of mail systems that are injecting messages into the global Internet.
It cites a range of specifics, for performing those practises, notably
with respect to some security functions. Mostly, it cites those
specifics in order to make give body to the higher-level recommendations
it is making. It does not particularly recommend one over the other, nor
do I believe it should.
Notably it does not invent any technologies or practices. Rather it
tries to document and recommend some broad operations practices that are
established and that result in some general improvements in the email
service.
The line of discussion about a particular algorithm reflects the rather
unfortunately tendency to have every system-level effort involving
security get dragged into low-level debates about basic algorithms and
about the current views of various experts in the security community.
That's no way to run a standards effort.
First, if the algorithm in question is so terrible, surely the large
number of folks using it would be experiencing some problems by now. It
is not as if we are lacking in attackers exploiting easy holes in
Internet services. And surely there would have been global alarums
raised about this algorithm, given its widespread use and it
weakenesses.
The current reality is that the ops and apps areas get to play a
guessing game, in the sure and certain knowledge that they will guess
wrong. The security community will always find fault with our choices.
Unless and until the security community can provide the applications and
operations community some common "packages" to use, just as transport,
network management and routing do, then we are never, ever going to make
serious progress using meaningful security.
Yes, I know the arguments for why this is difficult. And yes, I know
that security folk claim it is impossible because every service is
unique.
That's not good enough.
If the security is going to press for use of good security, then it
needs to provide far more turn-key solutions to those developing
services. Simply requiring that every service be developed with
security expertise and solutions that are unique to the service is a
model that clearly does not... scale.
Having debates about what is currently in vogue among various experts is
a fine thing to do... among the experts. But it is entirely
inappropriate to have these spontaneous debates in the middle of
pursuing a document specifying current practises.
If there is consensus among the security community that particular,
established practises are no longer viable, then please go through the
usual IETF processes for documenting community consensus about it.
At that point, it will make sense for the operations and development
community to adjust what it specifies.
Until then we are stuck with the vagaries of individual opinions and as
I recall, that's not what the IETF is supposed to be driven by.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf