Re: [saag] should we revise rfc 3365?

[Mouse <[e-mail]>]

>>> "MUST implement strong security in all protocols"
>> I believe this is too dogmatic a position, and will simply lead to
>> IETF process being ignored in [some cases].
> So how would you phrase it so that we do get security mechanisms
> defined in most all cases but not when they're really really not
> needed (or fictional)?

I don't think that can be done by drawing a hard line in the sand, as
3365 tries to do, regardless of where that line is drawn.  Whether
strong security is appropriate is a judgement call, as is how much
security constitutes `strong' for a particular purpose.  And judgement
calls have this annoying property that they require, well, judgement,
that they can't be made by unambiguous algorithms.

It's possible I'm just missing something, but I can't see any way to do
this that doesn't mean involving real humans.  3365 appears to be
trying to do it in a way that avoids needing to involve humans; I
believe that's possible only with a relatively high error rate.  In the
case of 3365, the errors take the form of imposing strong security on
protocols that don't need/want it; drawing the line other places will
distribute the errors differently, but I doubt it's possible to
eliminate them.

If this just resulted in unnecessary security, it wouldn't be so bad.
But I suspect it will, instead, result in IETF process being ignored
and protocols defined by rough consensus and running code _without_
IETF oversight, until/unless the IETF is more or less forced to either
violate its own process and standardize a protocol in its
widely-deployed form or blatantly ignore a popular and useful protocol
because it doesn't wear 3365's (or 3365bis's) straitjacket.

Of course, this is all my opinions and guesses.  I could be wrong.
Wouldn't be the first time, nor the last....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[e-mail]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B