Ned,
this is quality information, Thanks.
Ned Freed wrote:
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.)
( Indeed, I have advocated that as a potential solution. )
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.
( OK, interesting point. Not immediately applicable as RC4 does not
enter into the Open PGP debate. )
And given that backwards
compatibility was a nonstarter, the WG elected to go with the least encumbered
alternatives it could find.
( OK, so on the basis that RC4 was out *becuase* it was a trade secret,
backwards compatibility was dropped. That however does not apply here.
)
Here's the good bits:
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.
OK. A slight point of clarification: encumbered algorithms as a MUST
should not be permitted if there are alternatives, presumably. MAY or
SHOULD is ok?
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.)
Ah. I don't understand your last "possibility with RSA" unless you mean
"possibility with Open PGP."
Yes, RSADSI are most unlikely to give this forum that license, given the
opposing standard. I wonder if IETF would take that to heart and insist
that if RSADSI were to give royalty-free license to S/MIME, they should
also give it to competitors? Probably, if the algorithm is to be useful
in an unencumbered way, then this must be the case!
But, yes, I see this as unlikely.
I now take it as a given that requiring encumbered technologies when
alternatives exist is a nonstarter in the IETF.
OK, I concur. Your explanation has convinced me of that: IETF will not
permit Open PGP to use unencumbered technologies because alternatives
are around.
That leaves me with the sad feeling that the Open PGP standard will
suffer from slow takeup outside the US. I guess that's the lookout that
this forum has accepted from the start.
( It would appear that the IESG assumes that encumbered within the US is
equivalent to encumbered within the IESG, whereas encumbered within
France is not. I also agree with these Internet politics :-)
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.
Your explanation provides the middle and ending as well. Thanks again.
On a related issue, that of an unencumbered reference implementation. I
have heard it said that this was required. Is this the case, as it
would seem to be in your careful use of the word "technologies" above?
And if so, was pgp5.0 proposed and accepted as the reference
implementation at the Munich BOF?
--
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com