If you look at what has been happening in the IETF lately you'd see that
TLS, IPSec, and PKIX have all run into this issue.
I'm not sure about the examples, but I think the basic idea here is pretty
close to the mark.
The problem with TLS was that it didn't specify a mandatory-to-implement
ciphersuite. Without one it is impossible to meet IETF interoperability
requirements. This caused it to be bounced back to the WG for further work. In
other words, it wasn't the choice of a mandatory ciphersuite that mattered, it
was the lack of one. (I thought I'd mention this in case someone advocates
not having any mandatory-to-implement algorithms in OpenPGP.)
Having said that, the WG was also clearly unable to go with RC4, since RC4 is
considered to be a trade secret and IETF rules absolutely forbid standardizing
on material with confidentiality constraints. And given that backwards
compatibility was a nonstarter, the WG elected to go with the least encumbered
alternatives it could find.
I'm not familiar with the IPSec or PKIX situation so I cannot comment on them.
However, regardless of what happened to TLS, the fact of the matter is that the
rules are now in a state of flux. We all know what RFC 2026 says. But things
have changed since it was written.
For one thing, the IESG in general and the security AD in particular clearly
feel in light of past bad experiences with encumbered technologies that
embracing standards that require them is not a good idea. This is especially
true when perfectly viable alternatives are available.
For another, there's the matter of the plenary session in Munich. A straw poll
was taken there and a clear consensus emerged that use of encumbered
technologies should not be allowed when alternatives are available.
Far more than anything else, the IETF is ruled by rough consensus. So a straw
poll taken under such circumstances carries real weight, especially when it
tightens the rules rather than loosening them.
I now call this the "Munich doctrine". It joins the "Danvers doctrine", which
was the decision to refuse to cater to export requirements in regards to
security issues in IETF protocols. Neither of these are written down in an RFC
as far as I know, but both are very real nevertheless.
Remember that all it takes is two IESG members voting "NO" and the document
goes back to the WG. (The IESG, BTW, is the one place where voting is
sanctioned in the IETF.) My read of the situation is that there are at least
three and probably more IESG members who will vote against any specification
that requires use of encumbered technology where alternatives are available.
The DNSsec people have taken this to heart, that's for sure. They have made
arrangements with RSADSI for royalty free use of RSA in the DNS. (Unfortunately
I doubt this is a possibility with RSA.)
I now take it as a given that requiring encumbered technologies when
alternatives exist is a nonstarter in the IETF.
Analyzing the document rather than studying the context is not necessarily
the way to look at things when dealing with the IETF standards process.
Exactly right. This is a dynamic process. There's always more to it than what
is said on paper. So while I do recommend that people read what's on paper, it
should only be taken as a starting point.
Ned