Also worth bearing in mind, I think, that in the lifecycle of any given technology, the phases that are most laid open to a culture of peer inspection and challenge are the R&D and the standardisation phases.
The subsequent implementation and deployment phases are, by their nature, far less likely to be conducted openly or subjected to unrestricted external review (as opposed to comparatively constrained audit). As Dean says, the pragmatic approach isn't to try and eradicate the possibility of bad actors, but to adopt a way of working that minimises their chances of action and or success. My personal view is that the current way of working is less bad in that respect than any of the alternatives. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: [email protected] Phone: +44 705 005 2931 Twitter: @futureidentity On 3 Nov 2013, at 18:01, Phillip Hallam-Baker wrote: > > > > On Sun, Nov 3, 2013 at 3:54 PM, Dean Willis <[email protected]> wrote: > > On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" <[email protected]> wrote: > > > > > One of the issues that has been raised in the government world is how do we > > convince people looking in that the IETF spec have not been contaminated by > > some of the alleged $250 mil/yr being spent on such purposes. > > > > This is not a theoretical problem or even a new one, but it is one that has > > been ignored in the past and is now going to be very much harder to ignore. > > > > I'm pretty sure I got "persuaded" into buggering some security in RFC3261 > (sips: allowed to terminate at serving proxy rather than being e2e), at least > to the extent of accepting and endorsing a flawed argument that I now believe > would have made somebody's intercepts easier. Fortunately it turned out not > to matter much (as the defacto deployment was "no security" rather than the > piece I watered down), and it is now well-understood as an error. > > So it happens. Sometimes directly, sometimes indirectly as when your customer > or client is influenced into influencing your standards work. > > I didn't even realize what it was when it happened to me, and I used to think > I was pretty good at that game. Once burned, twice shy and all that. > > So I believe it can and does happen. Usually subtly, but I've also heard of > much more overt instances. Fortunately hearsay is inadmissible. > > But we do have to be careful, and we really need to build up a system that > anticipates and survives bad actors, even of the most deliberate sort. > > We live in a glass house, and people are now looking in. Rocks will be > thrown. Wear your slippers and safety glasses. > > -- > Dean > > > Have to remember that another possible mode of knobbling s spec is to > persuade the WG to include a feature that will make deployment impractical. > > So 'weakening security' is not necessarily a sign of knobbling... > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
