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

Reply via email to