Subject: Re: [perpass] Standards in the age of pervasive suspicion Re: NSA inspired PKIX limitations?

From: Dean Willis <[email-masked]>
Date: Sun, 3 Nov 2013 14:54:56 -0600

On Oct 21, 2013 3:21 PM, "Phillip Hallam-Baker" <[email-masked]> 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

---

From: Melinda Shore <[email-masked]>
Date: Sun, 03 Nov 2013 12:56:32 -0800

On 11/03/2013 12:54 PM, Dean Willis wrote:
> Fortunately hearsay is inadmissible.

INDEED.

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 3 Nov 2013 21:01:08 -0500

On Sun, Nov 3, 2013 at 3:54 PM, Dean Willis <[email-masked]>wrote:

> So I believe it can and does happen. Usually subtly, but I've also heard
> of much more overt instances. Fortunately hearsay is inadmissible.
>

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/

---

From: Robin Wilton <[email-masked]>
Date: Mon, 4 Nov 2013 13:36:27 -0800

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-masked]
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-masked]> 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.
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 02:07:26 -0500

People seem to have missed my actual points which were that

1) We have to accept the fact that people are going to be suspicious of
standards proposals and make sure that 'trust us' is not baked in. That
includes specs that assume one of the i-* entities is going to be
trustworthy in perpetuity.

2) People who take offense at the fact that they are under suspicion are
now in the wrong business. Being in the CA business I have always had to
justify the trust vested in my employer as a trusted third party, anyone
who takes offense when being asked why they should be considered
trustworthy should not be in the trusted third party business.

3) Yes it sucks, blame those idiot colonels whose crappy tradecraft led
them to write hundreds of powerpoint slides boasting about them and leave
them all on a sharepoint server administered by a 29 year old contractor
whose girlfriend worked as a stripper.

I do not think pervasive suspicion is really acceptable in the IETF culture
at present. Well not unless the target is a CA.

We also have a big problem in that there are two ways that an NSA
contractor can sabotage a standard. One is to obstruct changes to make a
standard secure, the other is to insist on ludicrous security requirements
that ensure nobody will use the security.

On the implementation side, yes, implementation errors whether fortuitous
or deliberate are much more likely to be the source of insecurity than
protocol errors. The number of developers is much larger than the number of
designers.

I get rather fed up of people who work for software vendors that patch a
dozen serious security bugs every month putting up slides that ignore their
own security problem but are sure to raise the DigiNotar issue.