On 9/20/2013 8:25 AM, Noel Chiappa wrote:
Iff enough people are _carefully_ reviewing specs, that ought to find all the
backdoors. An open process does have potential issues, but it's also the one
with the best chance of producing a 'good' product.
As has been said, the premise of open standards work is that it is
subject to broad review, as a quality assurance process. This is
expected to find errors -- and please forgive me for considering a
backdoor mechanism to merely be a really bad error.
But this requires that diverse, aggressive, expert reviews do get done,
with a special eye towards serious errors such as backdoors.
Sometimes we get those, sometimes we don't. We make the assumption that
the considerable array of late-stage reviews done now provide the
necessary assurances, but really they don't. (The original DKIM spec
was well and highly reviewed prior to publication. Imagine my surprise,
when we started the -bis effort, to discover the a critical algorithm
was so badly written it didn't work. The accompanying prose was pretty
good, but the pseudo-code wasn't.)
So we need to worry about active efforts to get diligent reviews that
look for certain classes of strategic problems. This probably requires
three things:
* Ensuring clarity and simplicity in the technology and the
specification writing make the work more accessible. Hence we ought to
seriously consider earlier-stage efforts to ensure that, at least for
any protocol that carries "interesting" security sensitivities.
* Some community agreement about the nature of problems to look for.
* For those sensitive specifications, soliciting additional expert
review, to consider robustness, reliability, and weaknesses such as
backdoors.
On 9/20/2013 7:48 AM, Carsten Bormann wrote:
> On Sep 20, 2013, at 13:38, Hannes
schofenig<hannes(_dot_)tschofenig(_at_)gmx(_dot_)net
> wrote:
>2) Are there documents you find non-readable?
> I'm not sure you aren't mocking us, but...
>
> *Yes*, there are documents in the IETF that are highly non-accessible.
The IETF approach to specification writing is unusually free-form. It
has the considerable benefit of permitting far more pedagogy that most
other groups use. This allows the document to establish its context,
comment on technical choices and comment on use; but that then creates
challenges for finding balance.
But often it also means that documents are poorly organized and frankly
poorly written, as folks have been noting. Such problems make a
document more obscure and therefore easier for adding hidden 'features'...
On 9/20/2013 8:28 AM, Steve Crocker wrote:
> Are we conflating back doors in implementations with back doors in
> protocol specifications?
We certainly need to be careful to distinguish between these. We have
direct responsibility for dealing with the latter. Normally we stay
hands off of the former.
However for 'sensitive' functions, we might want to press for industry
effort to ensure that the implementations -- especially the widely
re-used open systems versions -- haven't introduced essentially systemic
exposures.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net