Subject: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

From: <[email-masked]>
Date: Wed, 4 Dec 2013 22:05:15 +0000

(fixing ietf-http-wg address from ietf.org to w3.org)

Perens' response at
http://perens.com/works/ietf/perpass/appropriate-response/01.pdf (not an internet draft, sigh - alienate your readers before they start!)
commenting on
http://tools.ietf.org/html/draft-farrell-perpass-attack
gives some of the reasons in support of universal encryption not being a laudable goal.

This is a political problem, not a technical problem. From a technical perspective, caching static content matters. Trying to figure out problems that aren't security problems matters. Mandating secure communications for worldwide http is pretty much the same as mandating secure encrypted email worldwide - large failure modes, resulting in an inability to communicate. Which is why use of secure email is not widespread.

As IETF security AD, Farrell's response must always be 'we need more security'  and his draft - everything is an attack - is a reflection of that outlook.

One recent time everything was viewed as an attack was in Digital Rights Management by content providers. The result of DRM was to impose massive technical costs and shift the modes of attack on content. If you want to consider the failure modes of a secured web with secure communications everywhere, consider the failure modes of DRM. Meanwhile, the content providers pursued legal remedies as more effective. Is the IETF now advocating a DRM approach, when legal remedies would be more appropriate?

Any security system or algorithm, can be broken; when it is, it is considered as no longer fit for purposes, unfashionable, and to be discarded. Security is always raising the bar - e.g.  MD5 is no longer secure enough for security purposes (though still excellent in limited context as a reliability check for large files), SHA256 may not be strong enough... this is an upgrade cycle that eventually every implementation steps off, becoming incompatible with the latest and greatest. And this upgrade cycle will break the web into little pools of not-compatible-with-latest security as a result. One way to avoid that cycle is to always permit interoperability without security. (warn as much as you like, but permit it.)

The benefits of interop testing, less power drain, less complexity, and of actually being able to communicate if that is desired. are worthwhile. Demand security everywhere if you like, and treat everything as an attack, just as DRM did, but, as with DRM, it's a fool's errand.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: Ted Lemon [[email-masked]]
Sent: 04 December 2013 21:27
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; IETF Discussion; perpass; [email-masked]
Subject: Re: perens-perpass-appropriate-response-01

On Dec 4, 2013, at 4:17 PM, <[email-masked]> <[email-masked]> wrote:
> Universal encryption is not a a laudable goal.

Unsupported assertions are not helpful.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Dec 2013 17:42:43 -0500

> This is a political problem, not a technical problem. From a technical perspective, caching static content matters.  Trying to figure out problems that aren't security problems matters. Mandating s…

I take it you haven't been reading the responses to Bruce's essay, or you would have seen that these points have already been discussed and refuted.

---

From: Bruce Perens <[email-masked]>
Date: Wed, 04 Dec 2013 14:52:06 -0800

On 12/04/2013 02:42 PM, Ted Lemon
wrote:

I take it you haven't been reading the responses to Bruce's essay,
or you would have seen that these points have already been
discussed and refuted.

That might have been an accurate statement if this were a technical
discussion rather than a political one. We saw opposing viewpoints.
Opposition isn't refutation.

Thanks

Bruce

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Dec 2013 17:57:04 -0500

On Wed, Dec 4, 2013 at 5:52 PM, Bruce Perens <[email-masked]> wrote:

>  On 12/04/2013 02:42 PM, Ted Lemon wrote:
>
> I take it you haven't been reading the responses to Bruce's essay, or you
> would have seen that these points have already been discussed and refuted.
>

When someone starts accusing everyone of treason it isn't so much
refutation that is appropriate as the men in white coats.

-- 
Website: http://hallambaker.com/

---

From: <[email-masked]>
Date: Wed, 4 Dec 2013 22:55:49 +0000

Where are these being discussed? It's a response to an IETF draft, ergo [email-masked] is entirely appropriate. That Perens doesn't submit it as an internet-draft in response just suggests lack of political nous.

Way to go on the selective quoting - I see you ignore the DRM point. Sheesh, you can't even give a pointer to the refutations you apparently cite.

Don't you have anything substantial to say yourself, other than snarky oneliners?

Lloyd Wood

________________________________________
From: Ted Lemon [[email-masked]]
Sent: 04 December 2013 22:42
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; IETF Discussion; perpass; [email-masked]
Subject: Re: Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Dec 2013 18:06:51 -0500

> Where are these being discussed? It's a response to an IETF draft, ergo [email-masked] is entirely appropriate. That Perens doesn't submit it as an internet-draft in response just suggests lack of…

On the perpass mailing list.

> Way to go on the selective quoting - I see you ignore the DRM point. Sheesh, you can't even give a pointer to the refutations you apparently cite.

This too has been discussed.   The point in the case of DRM is that while DRM is indeed, as you say, eminently breakable, breaking it is inconvenient.   So putting DRM on everything increases costs for those who want to see the plaintext of everything.

> Don't you have anything substantial to say yourself, other than snarky oneliners?

I try not to repeat points that people smarter than I have already made, but I do take your point that this discussion is sufficiently widely splattered that nobody can possibly have followed every bit of it.

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 4 Dec 2013 18:11:33 -0500

On Wed, Dec 04, 2013 at 06:06:51PM -0500, Ted Lemon wrote:
> I try not to repeat points that people smarter than I have already
> made, but I do take your point that this discussion is sufficiently
> widely splattered that nobody can possibly have followed every bit
> of it.

After seeing Bruce accuse everyone who is trying to add encryption to
prevent pervasive security to be a traitor, I decided that there was
not much to be added by continuing to engage him in a discussion.

I have full faith that the IESG, after the last call process, will
give Bruce's comments all the weight that they deserve.

Regards,

					- Ted

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Dec 2013 18:38:08 +0000

Hi Lloyd,

On 12/04/2013 10:55 PM, [email-masked] wrote:
> I see you ignore the DRM point.

I don't understand your DRM point to be honest. It also does not seem to
be relevant to this conversation. DRM standards have not been been
developed in the IETF either.

draft-farrell-perpass-attack-00 does not specific solutions (which it
states in the document).

If your argument is that security adds complexity to protocols then
that's certainly true. The other option would be not to have security in
protocols at all to make them "more lightweight". Do you seriously think
that this is useful option (even before the NSA revelations)?

If your argument is that security problems on the Internet should be
solved via legal / regulatory ways then please go ahead an make these
proposals. Obviously, the IETF would be the wrong forum to do that. I am
sure the European Commission, for example, is interested to listen to
your proposals and will immediately issue new proposals for regulation.
It would be great if those you think that there are regulatory solutions
would in fact then work on those rather than just having technically
minded people who push problems around.

If your argument is aging cryptographic algorithms require software to
be updated then let me tell you that software gets updated even for
functionality reasons. Do you think that all the software updates you
get for you smart phone apps are only security fixes? There are,
however, many software updates that relate to security vulnerabilities.
My approach would, however, be to incorporate software update mechanisms
into products (which is what pretty everyone in the industry seems to be
doing) instead. While this is largely a non-IETF issue it would still be
interesting to hear whether you have other suggestions.

Your suggestions to do more interoperability testing sounds reasonable
to me. I have been involved in interoperability tests myself (and even
organized a few). Those tend to have a different focus, namely to
provide feedback about whether the implementations interpreted the specs
correctly. Penetration testing is what you would typically do to
discover security vulnerabilities. We typically don't do those (at least
not that I have heard). As such, I would rather seen them as a
orthogonal effort (which many in the IETF are involved in already
anyway). Are you suggesting that we should also do penetration testing?

Please also note that "security" is not a monolithic block, as you can
see from RFC 3552. In various discussions with you I got the impression
that you dislike security in general. That can hardly be true since I am
sure you like some of the security features in there as well. For
example, you might find authentication a pretty cool concept to avoid
others accessing your email account.

Ciao
Hannes

---

From: Bruce Perens <[email-masked]>
Date: Wed, 04 Dec 2013 15:35:56 -0800

On 12/04/2013 03:11 PM, Theodore Ts'o
wrote:

After seeing Bruce accuse everyone who is trying to add encryption
to
prevent pervasive security to be a traitor

This is a completely unwarranted ad hominem, Ted. Nobody has been
accused of being a traitor. I warned the group that they were at
risk of getting in legal trouble wherever they are. That's my honest
opinion.

Bruce

---

From: Bruce Perens <[email-masked]>
Date: Wed, 04 Dec 2013 15:35:59 -0800

On 12/04/2013 02:57 PM, Phillip
Hallam-Baker wrote:

When someone starts accusing everyone of treason it
isn't so much refutation that is appropriate as the men in
white coats.

Oh, come on Phillip. I did not accuse anyone, I said that it was
arguably criminal or treasonous, and warned of the danger to you.

I work for law firms all day, bridging technology and law. I think

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Dec 2013 10:40:16 +1100

Hi,

Can folks please stop cross-posting this to the HTTPbis WG? I'm sure we'll become aware of any relevant outcome of the discussion, and interested folks can join over on perpass.

Thanks,

--
Mark Nottingham   http://www.mnot.net/

---

From: Bruce Perens <[email-masked]>
Date: Wed, 04 Dec 2013 15:43:50 -0800

On 12/04/2013 03:35 PM, Bruce Perens
wrote:

When someone starts accusing everyone of treason it
isn't so much refutation that is appropriate as the men
in white coats.

Sorry, incomlete sentence. Should be:

I think that some IETF participants, somewhere, and some browser
implementors, somewhere, potentially have a legal problem. I would
hate to see you treated the way some security experts have been
treated. IMO you ignore that risk at your peril.

Thanks

Bruce

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 04 Dec 2013 23:52:39 +0000

Bruce Perens:
> On 12/04/2013 02:57 PM, Phillip Hallam-Baker wrote:
>>
>> When someone starts accusing everyone of treason it isn't so much refutation 
>> that is appropriate as the men in white coats.
> Oh, come on Phillip. I did not accuse anyone, I said that it was arguably 
> criminal or treasonous, and warned of the danger to you.

It was very clearly implied and your general tone is so shitty, I had to
read some headers to ensure you weren't being impersonated.

I work on cryptographic software that does exactly what you suggest and
we've been at it for ten years; your legal advice seems totally off base
and frankly, unhelpful to those working on both political and technical
solutions. Talk about FUD!

> I work for law firms all day, bridging technology and law. I think

Have you asked anyone at the EFF what they think of your legal opinions?
I think they'd get a good laugh out of it and then they'd probably give
you some reading material.

Sincerely,
Jacob

---

From: Bruce Perens <[email-masked]>
Date: Wed, 04 Dec 2013 16:14:02 -0800

On 12/04/2013 03:52 PM, Jacob Appelbaum
wrote:

It was very clearly implied and your general tone is so shitty, I
had to
read some headers to ensure you weren't being impersonated.

Well, you are reading me wrong. Please stop now.

Have you asked anyone at the EFF what they think of your legal
opinions?

I have been in the position of stating my intention to violate
national law and having EFF advise me to stop for my own safety. It
was a DMCA issue. EFF does not advise you to put your own head on
the block.

It's not what your software does, Jacob. It is the fact that folks
here clearly and publicly presented this as not just a way to stop
some random bad actor, but a way to stop NSA. For many of them, a
branch of their own government's defense department. And I just told
them they were ill-advised!

Thanks

Bruce

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 05 Dec 2013 00:37:33 +0000

Bruce Perens:
> On 12/04/2013 03:52 PM, Jacob Appelbaum wrote:
>> It was very clearly implied and your general tone is so shitty, I had to read 
>> some headers to ensure you weren't being impersonated.

I'm not clear that I am reading you incorrectly.

> I have been in the position of stating my intention to violate national law and 
> having EFF advise me to stop for my own safety. It was a DMCA issue. EFF does 
> not advise you to put your own head on the block.

Ill advised again:

  https://www.eff.org/nsa-spying

So really, ask some folks at the EFF about your legal views here? They
literally advise people to use Tor to defend against what they view as
illegal state surveillance by the NSA:

  https://ssd.eff.org/foreign/summing-up

> 
> It's not what your software does, Jacob. It is the fact that folks here clearly 
> and publicly presented this as not just a way to stop some random bad actor, but 
> a way to stop NSA. For many of them, a branch of their own government's defense 
> department. And I just told them they were ill-advised!

The very same department that is not legally allowed to spy on those
Americans, I might add.

We're probably going to have to agree to disagree at this point. I'd be
happy to buy you a drink to discuss this in person - if you happen to be
attending the CCC 30c3 in Hamburg, I think it would make for a great
discussion.

All the best,
Jacob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Dec 2013 23:03:59 -0500

> criminal or treasonous, and warned of the danger to you.

It seemed like more of a threat to me.

The NSA is very aware of the work that I am doing and its purpose. I
presented the work at MIT the week before Vancouver with several current
NSA employees present and a former NSA director.

One thing we know the NSA is going to need is usable data level security.
The only thing that differentiates my proposal from previous ones is that
(1) it requires exactly the same degree of effort as regular mail, (2) it
does not depend on building out infrastructure before deployment and (3) it
supports a policy layer so that in addition to discovering the recipient's
key, an application can determine the security policy of the recipient.

In other words, what differentiates my proposal is that it has a chance of
keeping Britain, American and their allies safe against the attacks that
are now going to be coming from all the other governments that are now
going to be playing copycat in the wake of Snowdonia.

The NSA is charged with two missions, not one. Protecting the US and its
allies from attack is far more important than attacking other countries.
The US has an electricity infrastructure that would embarrass many third
world countries, it has been defeated by squirrels let alone cyber-attacks.

Cyberwarfare has many of the same characteristics as terrorism. the
barriers to entry are low. It is inherently non-attributable and so
deterrence is infeasible. Any attempt to set red lines opens up the risk of
a false flag attack. And what might shock you is that people who have spent
their lives studying war had to have that pointed out by me.

Cyber is inherently destabilizing. And the risk is not just of a cyber
attack against the US and its allies. An attack against Russia or China
could lead to catastrophic consequences as well. Neither has the capacity
to develop an effective cyber defense in their critical infrastructure
unless the western powers develop the technology first. One of the ugly
costs of relying on industrial espionage is that it destroys any chance of
developing an indigenous research capacity.

The issues are vastly more complex than you imagine. NSA 1.0 spent its time
cracking mechanical ciphers to enable the CIA coups that stopped when the
world moved to digital in the mid 70s. NSA 2.0 grew large fat and lazy
while its military management spent their time boosting each other's egos
with (unsecured) Powerpoint presentations that almost certainly exaggerate
their capabilities.

We don't know what NSA 3.0 is going to be doing but it isn't going to have
anything like the intercept capabilities of the past and it will be two
congresses before they have any ability to shape the political landscape
again.

---

From: Bruce Perens <[email-masked]>
Date: Wed, 04 Dec 2013 21:18:52 -0800

>It seemed like more of a threat to me.

I can't imagine what I have to threaten with. No, it was not a threat.

>The NSA is very aware of the work that I am doing and its purpose.

And your description doesn't make it sound as if it's intended to be a hinder to NSA.

We were discussing the proposal to make the task of mass surveillance more difficult for one or more nation's intelligence services.  That is where I feel the risk (not threat) is.

>We don't know what NSA 3.0 is going to be doing but it isn't going to have anything like the intercept capabilities of the past

Since you can now get an ASIC bitcoin miner that does 10 giga hashes per second for around $240, we might have to adjust our capabilities assessment on the assumption that espionage agencies have custom silicon that we've never heard of, and lots of it. I don't think we can say for sure that TLS is any hurdle to NSA's mass surveillance program at all.

Thanks

Bruce
-- 

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 5 Dec 2013 10:40:28 +0100

On Wed, Dec 04, 2013 at 09:18:52PM -0800,
 Bruce Perens <[email-masked]> wrote 
 a message of 27 lines which said:

> I don't think we can say for sure that TLS is any hurdle to NSA's
> mass surveillance program at all.

Besides obvious remarks (secret agencies are secret), what is the
consequence to draw from this observation? That we should not use TLS
because it is possible that NSA has successfully attacked it? If so,
that would be a poor decision. First, there are other attackers, which
do not have the same resources as the NSA. Second, even the NSA cannot
break the law of physics (testing 2^256 possibilities take a lot of
time, even when you have money). Third, since we don't know, it seems
to me the reasonable thing to do would be to protect ourselves, just
in case.

[Insert here paranoid remarks about the NSA spreading the rumor that
it can break TLS so people won't encrypt and therefore the NSA will
not have to break TLS.]

---

From: Josh Howlett <[email-masked]>
Date: Thu, 5 Dec 2013 10:53:12 +0000

>>
>>This is a political problem, not a technical problem. From a technical
>>perspective, caching static content matters.  Trying to figure out
>>problems that aren't security problems matters. Mandating secure
>>communications for worldwide http is pretty much the same as mandating
>>secure encrypted email worldwide - large failure modes, resulting in an
>>inability to communicate. Which is why use of secure email is not
>>widespread.
>

Without naming specific territories, pervasive monitoring of the kind that
has motivated this discussion has been imposed on a very large part of the
world's Internet-connected population for many years, in full knowledge of
the technical community (and, indeed, the educated layman); and allegedly
assisted by some of the well-known vendors represented here.

All that has happened is that the technical community, who are largely
based in other world regions, has just discovered that it, too, has been
subject to this pervasive monitoring. It is the indignation and affront
arising from the sudden closure of the gap between expectation and reality
that is driving this, not any novel specific technical threat or
vulnerability.

It is worth reflecting on what the reaction of the IAB/IESG might have
been if these revelations had surfaced shortly before IETF 79, rather than
around the bastions of liberalism in Berlin and Vancouver. Probably
somewhat different.

And let's not forget that many within the industry will have been aware of
the generalities of the monitoring before the disclosures, even if they
weren't familiar with the operational detail.

This is, therefore, most assuredly a political problem. But that is not an
argument not to increase security.

I fully support action to increase security, where it responds to the
prevailing threat environment. But it will be a perpetuation of the
naivety that has characterised this debate to think that this alone will
halt pervasive monitoring, because the threat is not technical in nature.
The technical response must be coordinated with a political response, or
else the perpetrators will find political means to route around the
technical measures.

The political response shouldn't be organised within the IETF, but it does
need to liaise with those responsible for doing that. Unfortunately I am
not observing any movement by any of the other parties within our
wonderful multi-stakeholder system that you would think would be
notionally responsible for this. My fear is that they are opting to drink
the technology Kool-Aid, to avoid grasping the political nettle. That is
what should be concerning us right now.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Dec 2013 11:09:57 +0000

Josh,

> halt pervasive monitoring, because the threat is not technical in nature.

Personally, I think anyone using the argument that "you can't solve
the problem therefore do nothing" is talking about the same amount
of nonsense as anyone who says "the IETF can halt pervasive monitoring."

You don't quite say either of those above, but neither do you
acknowledge that the draft in question, and all the sensible discussion
(which is far from all the discussion;-) around that fully acknowledges
that the technical things that can and should be done are only part
of the story.

> else the perpetrators will find political means to route around the

I disagree with "must be coordinated" for various reasons.

Given the time it takes for us to do our part, which is measured
in years before we get good deployment, imposing a requirement
to start with coordination would mean doing nothing ever.

Secondly, with whom would we coordinate? Again, trying to impose
a requirement for coordination with a non-existent Internet-wide
political entity is tantamount to doing nothing.

If some other folks outside the IETF are working on the same
issues that'll be good or bad, and for some such activities it'll
be useful for us to know about and consider them. And maybe it'll
be useful for others to know what we're up to, but we should
not wait.

> need to liaise with those responsible for doing that. 

"The" political response? You expect only one? Again, I don't
think we should hang around waiting - we should document the
consensus from Vancouver and then follow that through in our
normal work within working groups and elsewhere - considering
threats, including this one, as we develop protocols.

> Unfortunately I am

Fully disagree. Its us should be grasping nettles and working
to improve the security and privacy properties of our protocols.

Regards,
S.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 5 Dec 2013 12:28:45 +0000

Hi Stephen,

I absolutely agree that the technical work is necessary, but it is not
sufficient.

The political environment controls the legal and regulatory environment
within which CEOs, their lawyers, and the other minions whose role is to
minimise corporate risk exposure, take the decisions on which products and
services reach the market.

The technical community can obviously choose to do the work regardless,
but in the absence of conformant products and services it runs the risk of
being a paper exercise.

I am sympathetic to your argument that the technical work could happen in
advance of policy, but that hands the advantage to the adversary who can
use this intelligence to advance blocking political measures.

I also agree that it is unfortunate that none of the numerous acronyms
that claim to have a remit in Internet policy are working with the
technical community. In the majority of the capitols of Europe there is
clearly a political appetite to roll pervasive monitoring back, and these
acronyms would be pushing on an open door (and, in fairness, perhaps they
already are but it is not obvious to the outside world). It is not far
from Geneva to Brussels...

Josh.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Dec 2013 12:40:44 +0000

Josh,

> I absolutely agree that the technical work is necessary, but it is not

So you agree this draft is necessary? If so, good.

Nobody (sensible) claimed it was sufficient by itself to stop
pervasive monitoring. It can nonetheless improve the Internet
in any case, both when considering the pervasive monitoring
threat and other threats. If e.g. the UTA WG is chartered later
today then what they're going to do, which is directly spurred
by this overall discussion, could significantly improve e.g. SMTP
security.

> but in the absence of conformant products and services it runs the risk of

That seems to apply to any new work that anyone does in the
IETF and is not a reason to do nothing.

> advance of policy, 

That is not my argument. The technical work should happen and
for technical reasons.

> but that hands the advantage to the adversary who can

Game theory is fun, but not particularly productive for this
draft IMO. That'd be more relevant for specific bits of
protocol work where it might be the case that one could consider
how an adversary could react to a particular mitigation for
this or other threats. At the level of this draft I don't think
there's anything useful to be done in that respect.

Cheers,
S.

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: Josh Howlett <[email-masked]>
Date: Thu, 5 Dec 2013 14:41:33 +0000

Stephen,

Yes I agree its necessary, but its not the hard part of the problem. We are focusing on implementation detail, at the expense of the meaty political problems; namely, (1) establishing the level of monitoring civil society is willing to tolerate (on the spectrum none to pervasive) and (2) building whatever legislative consensus is necessary to enforce that. Moving straight to (3) the solution space may deliver specs and running code, but not the motivations to deploy it (or worse, incentives not to). I applaud the effort, even if it only serves to incrementally improve on the status quo, but given your adversaries I fear it is already doomed before it has started. Seriously, best of luck anyway :-)

Josh.
________________________________
From: Stephen Farrell<mailto:[email-masked]>
Sent: ‎05/‎12/‎2013 12:41
To: Josh Howlett<mailto:[email-masked]>
Cc: perpass<mailto:[email-masked]>; IETF Discussion<mailto:[email-masked]>
Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Josh,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Dec 2013 14:55:18 +0000

On 12/05/2013 02:41 PM, Josh Howlett wrote:
> Stephen,
> 
> Yes I agree its necessary, but its not the hard part of the problem.
> We are focusing on implementation detail, 

Great, I think we agree on that, maybe with slightly
different emphases.

> at the expense of the meaty
> political problems; namely, (1) establishing the level of monitoring
> civil society is willing to tolerate (on the spectrum none to
> pervasive) and (2) building whatever legislative consensus is
> necessary to enforce that. 

Those may be good things for folks to do in various other
places, but I don't think they're for the IETF to do.

Cheers,
S.

> Moving straight to (3) the solution space
> may deliver specs and running code, but not the motivations to deploy
> it (or worse, incentives not to). I applaud the effort, even if it
> only serves to incrementally improve on the status quo, but given
> your adversaries I fear it is already doomed before it has started.
> Seriously, best of luck anyway :-)
> 
> Josh. ________________________________ From: Stephen
> Farrell<mailto:[email-masked]> Sent: ‎05/‎12/‎2013 12:41 
> To: Josh Howlett<mailto:[email-masked]> Cc:
> perpass<mailto:[email-masked]>; IETF
> Discussion<mailto:[email-masked]> Subject: Re: [perpass] Commnets on
> draft-farrell-perpass-attack-00 was RE:
> perens-perpass-appropriate-response-01
> 
> 
> Josh,
> 
>> I absolutely agree that the technical work is necessary, but it is
>> not sufficient.
> 
> pervasive monitoring. It can nonetheless improve the Internet in any
> case, both when considering the pervasive monitoring threat and other
> threats. If e.g. the UTA WG is chartered later today then what
> they're going to do, which is directly spurred by this overall
> discussion, could significantly improve e.g. SMTP security.
> 
>> The political environment controls the legal and regulatory
>> environment within which CEOs, their lawyers, and the other minions
>> whose role is to minimise corporate risk exposure, take the
>> decisions on which products and services reach the market.
>> 
>> The technical community can obviously choose to do the work
>> regardless, but in the absence of conformant products and services
>> it runs the risk of being a paper exercise.
> 
> That seems to apply to any new work that anyone does in the IETF and
> is not a reason to do nothing.
> 
>> I am sympathetic to your argument that the technical work could
>> happen in advance of policy,
> 
> That is not my argument. The technical work should happen and for
> technical reasons.
> 
>> but that hands the advantage to the adversary who can use this
>> intelligence to advance blocking political measures.
> 
> Game theory is fun, but not particularly productive for this draft
> IMO. That'd be more relevant for specific bits of protocol work where
> it might be the case that one could consider how an adversary could
> react to a particular mitigation for this or other threats. At the
> level of this draft I don't think there's anything useful to be done
> in that respect.
> 
> Cheers, S.
> 
>> 
>> I also agree that it is unfortunate that none of the numerous
>> acronyms that claim to have a remit in Internet policy are working
>> with the technical community. In the majority of the capitols of
>> Europe there is clearly a political appetite to roll pervasive
>> monitoring back, and these acronyms would be pushing on an open
>> door (and, in fairness, perhaps they already are but it is not
>> obvious to the outside world). It is not far from Geneva to
>> Brussels...
>> 
>> Josh.
>> 
>>>> I fully support action to increase security, where it responds
>>>> to the prevailing threat environment. But it will be a
>>>> perpetuation of the naivety that has characterised this debate
>>>> to think that this alone will halt pervasive monitoring,
>>>> because the threat is not technical in nature.
>>> 
>>> Personally, I think anyone using the argument that "you can't
>>> solve the problem therefore do nothing" is talking about the same
>>> amount of nonsense as anyone who says "the IETF can halt
>>> pervasive monitoring."
>>> 
>>> acknowledge that the draft in question, and all the sensible
>>> discussion (which is far from all the discussion;-) around that
>>> fully acknowledges that the technical things that can and should
>>> be done are only part of the story.
>>> 
>>>> The technical response must be coordinated with a political
>>>> response, or else the perpetrators will find political means to
>>>> route around the technical measures.
>>> 
>>> in years before we get good deployment, imposing a requirement to
>>> start with coordination would mean doing nothing ever.
>>> 
>>> issues that'll be good or bad, and for some such activities
>>> it'll be useful for us to know about and consider them. And maybe
>>> it'll be useful for others to know what we're up to, but we
>>> should not wait.
>>> 
>>>> The political response shouldn't be organised within the IETF,
>>>> but it does need to liaise with those responsible for doing
>>>> that.
>>> 
>>>> Unfortunately I am not observing any movement by any of the
>>>> other parties within our wonderful multi-stakeholder system
>>>> that you would think would be notionally responsible for this.
>>>> My fear is that they are opting to drink the technology
>>>> Kool-Aid, to avoid grasping the political nettle. That is what
>>>> should be concerning us right now.
>>> 
>>> Fully disagree. Its us should be grasping nettles and working to
>>> improve the security and privacy properties of our protocols.
>>> 
>>> Regards, S.
>>> 
>> 
>> 
>> Janet(UK) is a trading name of Jisc Collections and Janet Limited,
>> a not-for-profit company which is registered in England under No.
>> 2881024 and whose Registered Office is at Lumen House, Library
>> Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No.
>> 614944238
>> 
>> _______________________________________________ perpass mailing
>> list [email-masked] 
>  not-for-profit company which is registered in England under No.
> 2881024 and whose Registered Office is at Lumen House, Library
> Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No.
> 614944238
> 
> _______________________________________________ perpass mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Dec 2013 08:47:24 +1300

On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote:
(on a different list and under a differeny Subject header)
...

> Remembering of course that some platforms which wish
> to use the Internet simply do not have the capability for
> other than a very tiny very basic stack.
> 
> I always use the PIC and the Arduino to remind myself what the
> lower end of the franchise looks like.

It seems to me that perpass should think a little bit about
privacy and anti-surveillance issues for devices with tiny
stacks, and see if that calls for any specific IETF work items.

    Brian

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Dec 2013 15:04:24 -0500

> stacks, and see if that calls for any specific IETF work items.

This is not unexplored territory.
<http://tools.ietf.org/html/draft-ietf-core-coap-18>
<http://tools.ietf.org/html/draft-aks-crypto-sensors-02>
<http://tools.ietf.org/wg/dice/>

---

From: Robin Wilton <[email-masked]>
Date: Mon, 9 Dec 2013 21:50:11 +0100

And in some cases, a tiny stack is an advantage. It shortens the path whose trustworthiness one has to assure.

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 9 Dec 2013, at 21:04, Richard Barnes <[email-masked]> wrote:

> On Mon, Dec 9, 2013 at 2:47 PM, Brian E Carpenter <[email-masked]> wrote:

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 09 Dec 2013 12:56:42 -0800

We'll most likely find out sooner rather than later if this whole "Internet
of Things" materializes. :-)

That should only be a half-smiley above, since we are talking about 'smart'
TVs, home security systems, vacuum cleaners, etc.

- - ferg

On 12/9/2013 12:50 PM, Robin Wilton wrote:

 > On 9 Dec 2013, at 21:04, Richard Barnes <[email-masked] <mailto:[email-masked]>>
 > wrote:
 >
 >> On Mon, Dec 9, 2013 at 2:47 PM, Brian E Carpenter
 >> <[email-masked] <mailto:[email-masked]>>
 >> wrote:
 >>

-- 
Paul Ferguson
PGP Public Key ID: 0x63546533

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 09 Dec 2013 20:56:56 +0000

Many of us are actually thinking about how to get the IP stack on these
devices.

The IAB had a workshop in 2011 on smart objects and the report can be
found here: http://tools.ietf.org/html/rfc6574

We then had a workshop specifically dedicated to security in 2012:
http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02
(pending publication as an RFC).

There is even an IAB document in development that touches this topic:
http://tools.ietf.org/html/draft-iab-smart-object-architecture-03
(Comments welcome)

[Recent comments indicated that there is a desire to talk more about
IPv6, and the transition mechanisms. Great that we worked on so many --
will for sure make it easier to fit them all on these devices.]

As you know, we even have the IETF LWIG group that discusses these issues.

If you look at recent events, like the Internet census
http://internetcensus2012.bitbucket.org/paper.html, then it should be
clear that even "small device" need security since otherwise we are
building the next generation botnet. This would not be good (tm).

Ciao
Hannes

---

From: Martin Millnert <[email-masked]>
Date: Mon, 09 Dec 2013 22:55:36 +0100

> stacks, and see if that calls for any specific IETF work items.

I completely agree it's good to understand consequences on security
requirements.  That will probably follow naturally on the other hand,
once said requirements become known.  But what's more important, is what
failure to fulfill the requirements mean.

For example:
Requirements & considerations for mitigating pervasive passive
surveillance are <X>.
Device D or protocol P fulfills 50% of <X>.  Thus, D / P are not [insert
pervasive surveillance-resistant consumer logo here] compliant.

That would be some form of ideal information to possess, allowing
protocols & implementations, etc. to more easily be benchmarked on their
performance of surveillance-resistance.

Divide and conquer.  By enumerating and specifying the threats (on all
stack layers, even if implementation of mitigation is not up to IETF)
and what's generally required to avoid them separately from guidance on
how to avoid them, or guidance for protocol wg's, I believe we can
better avoid the... detours and distractions.

Vendors have been building TLS MITM for enterprises for a long time.
That is not necessarily going to be stopped by always-on-TLS in HTTP
2.0.  That, and how to balance bandwidth saving caching functions with
perpass-resistant protocols, is probably better discussed in their
respective wg's.
  What should be perfectly clear is however, that for example in HTTP
2.0, allowing transparent proxies, will score very, very low on
perpass-resistance.
  That benchmarking feature is IMO useful output from perpass following
draft-farrell-perpass-attack-02, which to me reads completely fine.

My 2c,
Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Dec 2013 10:58:17 +1300

Hannes,

> (pending publication as an RFC).

Fair enough, but did you consider specifically the privacy and
surveillance aspects? I'm concerned that counter-measures that can
be easily incorporated in full size devices may be too heavy for
tiny devices. If this is not a real concern, I will be delighted
of course.

And there is the usual problem of converting workshop conclusions
into WG action.

    Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 17:53:00 -0500

> <http://tools.ietf.org/wg/dice/>

COAP on a PIC? Really?

Or are you talking about the 32bit one rather than the 8 bit one that is
made in roughly double quantities year on year. The 8 bit one comes with
4Kbytes. I don't think you can get a TCP/IP stack in there.

But you do quite often need to get some form of end to end security from a
control system to an end point with a 6502 or Z80 class embedded device
that is connected over an I2C or RS485 link.

Right now that territory is occupied by MODBUS which is a protocol that
hasn't changed since I used it thirty years ago before I went to college.
It has no authentication or encryption and only limited error checking
capabilities. We run nuclear power plants off MODBUS but the folk who do
firework displays use MIDI because it has better error checking (oh I kid
you not).

We don't necessarily need to do IP end to end. I have never been a fan of
that particular dogma. IP is a rotten match for RS485 at 9600baud. But
being able to authenticate control messages and sensor readings end to end
is badly needed.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Dec 2013 18:03:07 -0500

> And there is the usual problem of converting workshop conclusions

As I recall, the major upshot of the workshop, from a security point of
view, was that (1) security protocols are tough but tractable, and (2) the
really hard problem is the introduction problem.  By which I mean:
Smart/IoT devices are going to, by their nature, talk to something else
(otherwise they wouldn't need connectivity).  The "introduction problem" is
the challenge of telling devices whom they should talk to, and how to
authenticate them, in such a way that doesn't allow an attacker to insert
himself, with the very limited interfaces that IoT devices tend to have.
 At one layer, it's just an authentication / authorization problem, but
it's one that has much more impact on hardware/software configuration than
on protocol.

That is my understanding, at least, of how we arrived at the current state,
where most of the protocol work is focused on making the security protocols
nicer (e.g., CoAP, DICE).  Nobody has found an approach to the introduction
problem that applies everywhere^Wa lot of places.

In point of fact, most of the interesting IoT vulnerabilities we've seen so
far have not been due to either of the above problems, but rather to
manufacturers making stupid decisions that couldn't have been fixed by any
number of RFCs.

--Richard

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 15:07:34 -0800

> manufacturers making stupid decisions that couldn't have been fixed by any

Do you mean to say that RFCs are not the place to address this
introduction problem, or that people ignore RFCs?  The latter is
something we already deal with; the former seems doable, were there
the will to do so.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Dec 2013 23:20:41 +0000

> it's one that has much more impact on hardware/software configuration than

Doesn't the same problem exist in homenet? Perhaps with more
immediately tractable devices, esp. if there's new work that
can be done in terms of avoiding pervasive monitoring. Could
be that homenet is an easier target for work related to this
space, at least initially.

> manufacturers making stupid decisions that couldn't have been fixed by any

Its not directly relevant to pervasive monitoring, but IMO the
worst security thing about tiny devices is the lack of s/w or
firmware update. Without that, we're basically screwed istm. And
we don't look like we're getting that, not even in proprietary
flavours. Or maybe I'm out of date on that? Would love to be.

S.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Dec 2013 18:21:23 -0500

> something we already deal with; the former seems doable, were there

I'm thinking of things like these...
<
http://thehackernews.com/2013/08/hacking-HP-printers-Vulnerability-wifi-password.html#
<http://bgr.com/2013/11/20/lg-smart-tv-spying/>

... which do not seem like RFC-able things (so, the latter).  Both are poor
design decisions; the first not applying authentication/authorization, and
the second, well, just epically failing. What are you going to do, require
someone to set a jumper for DNT?

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 10 Dec 2013 00:46:19 +0100

>someone to set a jumper for DNT?

  An LG Smart TV owner in the United Kingdom has shockingly discovered
  that his device is sending unencrypted data over Wi-Fi containing TV
  watching habits, as well as file names from external storage units
  hooked up to the TV to an LG website, even though the TV’s privacy
  settings should have prevented such behavior.

Next device this data will be sent encrypted, with the keys and the
software secured by the TV's "DRM" system so Smart TV owners will no
longer be able to find out about such problems.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Dec 2013 19:07:46 -0500

> longer be able to find out about such problems.

That actually seems like kind of a compelling rationale for
authentication-only modes (as Bruce suggested) -- so we the network owners
can see what our devices are doing.  It's isomorphic to the enterprise
case, but a little more intuitive for we end users.

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 00:19:07 +0000

> case, but a little more intuitive for we end users.

I disagree. As Bjorn says the device manuf will encrypt
next time no doubt irrespective of whatever HTTP does,
perhaps using the JS WebCrypto API;-)

May as well encrypt the HTTP then since you'll need to
spot the badness via traffic analysis yourself! (Only
kidding, the always-encrypt-HTTP argument isn't that
simple and should be rehashed here:-)

But yes, the privacy-unfriendly behaviour of our devices
and service providers is a major deal. I don't think that
justifies arguments to give up our privacy to everyone in
between though.

S

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 00:27:54 +0000

Oops

On 12/10/2013 12:19 AM, Stephen Farrell wrote:
> should be rehashed

I meant "should not be rehashed" ;-)

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Dec 2013 13:28:50 +1300

On 10/12/2013 12:20, Stephen Farrell wrote:
...
> flavours. Or maybe I'm out of date on that? Would love to be.

We're not screwed if (and only if) such devices can only communicate
with the rest of the world via some larger box. That needs to
include all forms of communication, of course, including near-field,
to avoid walk-by snooping.

Indeed I am not sure that's possible. At some point we'll need
to start suspecting give-away pens of being surveillance devices
distributed by the thousand.

     Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 19:43:21 -0500

> distributed by the thousand.

We are already at that point with USB memory sticks. Quite a few have ended
up being corrupted with malware.

There is certainly a need here and it is significant. But I think the
answers are going to have to be regulation and audits and the like.

What we can do about this in the IETF is quite limited. What we could do is
to have some sort of device registration protocol whereby the device gains
access to the network by first proposing a 'contract' specifying all the
ports and protocols it is going to speak. The network infrastructure could
then default-deny any access outside that contract.

This would then reduce the audit task from observing the behavior of the
device to checking the facilities it asks for and seeing if they are
acceptable.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 00:46:06 +0000

On 12/10/2013 12:43 AM, Phillip Hallam-Baker wrote:
> What we can do about this in the IETF is quite limited. 

Tend to agree. Maybe a good topic for that workshop in
London though. [1] :-)

S.

[1] http://www.iab.org/activities/workshops/strint/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Dec 2013 22:34:21 -0500

> [1] http://www.iab.org/activities/workshops/strint/

I already wrote my paper for that with my proposal for solving end-to-end
email.

I'll add a footnote to say that I have a solution but I can't fit it in the
margin, does that count?

Perhaps Satoshi Nakamoto could write a paper.

---

From: Robin Wilton <[email-masked]>
Date: Tue, 10 Dec 2013 07:46:49 +0100

If the margin doesn't provide you with enough space, perhaps you should re-Fermat it.

Robin Wilton

On 10 Dec 2013, at 04:34, Phillip Hallam-Baker <[email-masked]> wrote:

> On Mon, Dec 9, 2013 at 7:46 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> I already wrote my paper for that with my proposal for solving end-to-end email.
> 
> I'll add a footnote to say that I have a solution but I can't fit it in the margin, does that count?
>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 10 Dec 2013 12:24:40 -0500

On 12/9/13 7:43 PM, Phillip Hallam-Baker wrote:
> What we can do about this in the IETF is quite limited. What we
> could do is to have some sort of device registration protocol
> whereby the device gains access to the network by first proposing a
> 'contract' specifying all the ports and protocols it is going to
> speak. The network infrastructure could then default-deny any
> access outside that contract.
> 
> This would then reduce the audit task from observing the behavior
> of the device to checking the facilities it asks for and seeing if
> they are acceptable.

I have been thinking similarly... sort of a standards-supported
network monitor for the internet of things:

from p. 4 of
https://www.cdt.org/files/pdfs/CDT-Internet-of-Things-Comments.pdf:

"There may be technological solutions to these barrier-crossing issues
that consumers can configure to control the amount and nature of data
transmitted by IoT-capable sensors and devices in sensitive locations.
For example, it may be possible to design “middleware” networking
equipment that a member of the household or business could configure
to selectively allow or disallow networked objects from communicating
outside of the household network. Ideally, such a privacy appliance
could easily identify data emitted by IoT-capable products in the home
network, but that relies on manufacturers inserting the right tags into
their network communication that such an appliance could read. This
would probably require significant standards work and manufacturer
buy-in (or a legislative or regulatory mandate) to support this kind
of functionality. Another option may be to design a standard element
to the networkable components of IoT objects — say a pull-off tab or
shielding element — that consumers can activate in order to toggle or
disable networking functionality. Given that certain activities and
areas in one’s home are particularly sensitive towards arbitrary data
collection — bedrooms, bathrooms, children’s areas — there may be a
level of tracking and data usage that above which is simply not
appropriate for those products or that industry commits to making
connected and disconnected versions."

Would love to know if there is work (standards, research, whatever) in
this area I should be aware of.

best, Joe

- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Scott Brim <[email-masked]>
Date: Tue, 10 Dec 2013 13:50:23 -0500

> trustworthiness one has to assure.

... except that to keep unit costs down, usually they pick up code
from a low bidder.

---

From: Scott Brim <[email-masked]>
Date: Tue, 10 Dec 2013 13:55:01 -0500

On Mon, Dec 9, 2013 at 4:58 PM, Brian E Carpenter
<[email-masked]> wrote:
> tiny devices.

Brian: I'm not in the field but people I've spoken to have certainly
_considered_ the problems. I don't know what's made it into
deployment.  On the other hand, there's a good chance that industry
groups would be where these problems get worked on more than the IETF.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Dec 2013 20:41:22 -0500

On Tue, Dec 10, 2013 at 12:24 PM, Joseph Lorenzo Hall <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>

The first step is to have a protocol that allows a device, application,
whatever that is connecting to the local network to announce themselves and
the services they intend to provide.

If you would like to do this in JSON, I have a protocol to do that:

http://tools.ietf.org/html/draft-hallambaker-omnibroker-06

The explanation of how to manage the protocol is incomplete because I am
currently doing the email hack thing. But I do intend to finish this work
because I intend to build on it.

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Dec 2013 13:44:00 -0600

> stacks, and see if that calls for any specific IETF work items.

Always a good plan.

You might enjoy one of my former student’s books:

	• ASIN: B00GA2XKG8

Security for Wireless Sensor Networks using Identity-Based Cryptography by Patil, Harsh Kupwade (Jan 14, 2013)