Re: Transparency in Specifications and PRISM-class attacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.tschofenig@xxxxxxx
> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]