Subject: 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: <[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: 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: 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.
>
>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.

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: <[email-masked]>
Date: Fri, 6 Dec 2013 06:42:21 +0000

My argument is that security (confidentiality and encryption in transmission) should always be _optional_ in a transport protocol. Define a NULL cleartext ciphersuite if you have to, but do make cleartext transmission possible.

With the analogy with DRM, encrypting everything didn't work there. Why should it work here? What is gained, apart from a lot of overhead?

Allowing encryption to be optional:
- increases the chances of base interoperability.
- increases the chances of debugging problems in the field.
- increases the chance of the protocol even being implemented, or being implemented and used where the threat model does not require confidentiality or encryption as a response.
- makes lightweight implementations possible, which can scale down to be fit for purpose.

draft-farrell-perpass-attack notes:
"the IETF is not equipped to tackle the non-technical aspects of mitigating pervasive surveillance"

Well, yes. RFC2804 deliberately passed on the moral position of wiretapping surveillance, while draft-farrell-perpass-attack is appealing to vox populi as its argument. We're not even capable of articulating why pervasive surveillance is bad. We're just reacting to news reports.

Frankly, I don't think the IETF is well-equipped to tackle the technical aspects of mitigating pervasive surveillance either. I don't see evidence of that to date. 

I do not have confidence that the IETF can do good security protocol design together with good transport protocol design. My fear is that  the two will be combined into one by using draft-farrell-perpass-attack and its followons (hey, BCPs get updated) as a club to justify encryption in all transport protocols. This does not bode well.

Increasing the cost to the "attacker" means increasing the costs to the implementer and to the user, and to the designers, far more. It means increasing the complexity of the specification and implementation. It's complexity beyond what can be handled in committee. draft-farrell-perpass-attack can be considered an attack on IETF transport area work for those reasons. It's going to have more of an effect on the IETF than it will on the NSA.

Now, this isn't to say that the IETF shouldn't try to design secured protocols mitigating snooping for users - when there are actual users and use cases, and a threat model that requires consideration of privacy.  It should not be an indiscriminate blanket effort. But when an attempt fails to achieve that impossible goal of a secure protocol free from monitoring (and it will fail), having a transport protocol that still useful and workable in the clear once all of the has-been-found-to-be-broken-by-design-before-being-obsoleted security-stuff is stripped away is still an achievement. And that transport can still carry data encrypted at a higher layer. Which is what e.g. TLS is for...

Lloyd Wood

sure, you're speaking for security. Who is speaking for transport?

________________________________________
From: Hannes Tschofenig [[email-masked]]
Sent: 04 December 2013 18:38
To: Wood L  Dr (Electronic Eng); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Hi Lloyd,

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Dec 2013 11:57:48 +0000

Hi Lloyd,

(dropping httpbis, Mark asked to reduce their noise level
yesterday)

On 12/06/2013 06:42 AM, [email-masked] wrote:
> My argument is that security (confidentiality and encryption in
> transmission) should always be _optional_ in a transport protocol.
> Define a NULL cleartext ciphersuite if you have to, but do make
> cleartext transmission possible.

That is a good discussion to have, but isn't necessary or relevant
for this draft, which itself doesn't specify nor mandate any
particular mitigations. I think you're attacking a wrong target.

> With the analogy with DRM, encrypting everything didn't work there.
> Why should it work here? What is gained, apart from a lot of
> overhead?

There is a difference - with DRM, the user is considered the
adversary, in this case the adversary (in protocol terms) is
often a third party.

But yes, there are pervasive monitoring situations where the
adversary might be the service provider, but those are to some
degree outside the IETF's remit for now, except where we have
good e2e security options. Unfortunately, in many cases we do
not yet have good enough e2e security options that can be
deployed at Internet scale to handle such cases. But we should
continue to work at that. A case where we can provide e2e would
be XMPP, where OTR is a good proof that you can provide some
e2e security and the XMPP WG are working away at a standards
track e2e solution. (And separately some folks are writing up
an I-D on OTR I think.)

We are not however going to stop sending email just because
neither S/MIME nor PGP are good enough. And this draft won't
mean that anyone making such an argument (e.g. that we should
all use S/MIME all the time) will be able to use the resulting
BCP to force their wishes on an unwilling world.

What this BCP (when published) will do is ensure that someone
who has a good technical option doesn't have to re-litigate
the argument that pervasive monitoring is an attack that we
should mitigate.

> - increases the chance of the protocol even being implemented,
>   or being implemented and used where the threat model does
>   not require confidentiality or encryption as a response. 

In the context of a discussion of whether the IETF should
move beyond mandatory-to-implement, (MTI) I would argue
each of the above. But, that's not this discussion.

> draft-farrell-perpass-attack notes: "the IETF is not equipped to
> tackle the non-technical aspects of mitigating pervasive
> surveillance"
> 
> Well, yes. RFC2804 deliberately passed on the moral position of
> wiretapping surveillance, while draft-farrell-perpass-attack is
> appealing to vox populi as its argument. We're not even capable of
> articulating why pervasive surveillance is bad. We're just reacting
> to news reports.

We are quite properly reacting to newly presented and relevant
facts. Even if we don't have a full picture of all the facts,
its unquestionably the case that we have enough real information
to justify taking action.

> Frankly, I don't think the IETF is well-equipped to tackle the
> technical aspects of mitigating pervasive surveillance either. I
> don't see evidence of that to date.
> 
> I do not have confidence that the IETF can do good security protocol
> design together with good transport protocol design. My fear is that
> the two will be combined into one by using
> draft-farrell-perpass-attack and its followons (hey, BCPs get
> updated) 

BCPs only get updated after IETF last calls.

> as a club to justify encryption in all transport protocols.
> This does not bode well.

Fear not! Again, if your fear is of "more than MTI" then that is
not part of this draft but is a separate discussion.

> Increasing the cost to the "attacker" means increasing the costs to
> the implementer and to the user, and to the designers, far more. 

"far more"? I disagree. The high cost of using crypto was a fine
argument to make 20 years ago, but for almost all systems that's
no longer the case.

And if you look at the work e.g. Tero did for IPsec with no
certificate handling, (which I think is being documented in lwig)
its quite possible to do the crypto in very tiny devices. Doing key
management securely is harder in such such environments though
that is true, and would be something that relevant working groups
would take into account.

> It
> means increasing the complexity of the specification and
> implementation. It's complexity beyond what can be handled in
> committee. draft-farrell-perpass-attack can be considered an attack
> on IETF transport area work for those reasons. It's going to have
> more of an effect on the IETF than it will on the NSA.

I think that's nonsense fwiw. I suspect Lloyd and myself
won't have a meeting of the minds on the topic though;-)

S.

> Now, this isn't to say that the IETF shouldn't try to design secured
> protocols mitigating snooping for users - when there are actual users
> and use cases, and a threat model that requires consideration of
> privacy.  It should not be an indiscriminate blanket effort. But when
> an attempt fails to achieve that impossible goal of a secure protocol
> free from monitoring (and it will fail), having a transport protocol
> that still useful and workable in the clear once all of the
> has-been-found-to-be-broken-by-design-before-being-obsoleted
> security-stuff is stripped away is still an achievement. And that
> transport can still carry data encrypted at a higher layer. Which is
> what e.g. TLS is for...
> 
> Lloyd Wood http://sat-net.com/L.Wood/
> 
> ________________________________________ From: Hannes Tschofenig
> [[email-masked]] Sent: 04 December 2013 18:38 To: Wood L
> Dr (Electronic Eng); [email-masked] Cc: [email-masked];
> [email-masked]; [email-masked]; [email-masked] Subject: Re:
> [perpass] Commnets on draft-farrell-perpass-attack-00 was RE:
> 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).
> 
> 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)?
> 
> 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: <[email-masked]>
Date: Sun, 8 Dec 2013 05:56:48 +0000

Stephen,

I've no idea what you think you mean when you say 'moving beyond
mandatory to implement'. My take is that encryption should never be
mandatory to implement. Your unspoken assumption seems that it is first
always mandated, and then lifted under certain special circumstances.
That would be the wrong way around.

> argument to make 20 years ago, but for almost all systems that's

I did not discuss processing cost, though that's also relevant,
particularly for low-end systems.

My concern is that the cost to designers of trying to design
transport protocols becomes unacceptably high, as any attempt
to design a transport protocol becomes defending against the design
of what has just become a security protocol.

I view the failure of DTNRG work - where tailoring for the DTN
scenario was dropped in favour of emphasising security work, and
problems with the protocol would be fixed by the security framework,
but weren't - as an example of this. And where the IRTF leads,
the IETF follows.

If security wonks understood transport mechanisms, this might
be less of an issue. But as DTNRG ignored checksums and the
end-to-end principle for years, that seems unlikely. Security
has a cost, debating with security aficionados has a cost, defending
designs against security unneeded for use has a cost. I believe
that TCP and http are only widespread because security was not
part of their remits.

>> It means increasing the complexity of the specification and
> I think that's nonsense fwiw.

Of course you do.

But you wrote the ridiculously complex RFC6257, and focusing on that
sidelined transport work in DTNRG in the process - and a
delay-tolerant network is ultimately all about the transport. That nicely
demonstrates my fears.

> I suspect Lloyd and myself

Damn right.

Lloyd Wood
http://sat-net.com/L.Wood/dtn/bundle.html

________________________________________
From: Stephen Farrell [[email-masked]]
Sent: 06 December 2013 11:57
To: Wood L  Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Hi Lloyd,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Dec 2013 20:34:33 +0000

On 12/08/2013 05:56 AM, [email-masked] wrote:
> mandatory to implement. 

MTI security is what's called for by BCP 61. Sometimes the MTI
security for a protocol will involve confidentiality, other
times (e.g. routing protocols) it has tended not to. So your
"take" is at odds with long standing IETF BCPs.

> Your unspoken assumption seems that it is first

I also meant that. Arguing that we don't know how to engineer
this is also a fine 1990's era argument.

> but weren't - as an example of this. And where the IRTF leads,

Your and my descriptions of about 90% of things related to DTN
seem to be at odds. And that's the case here too.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Dec 2013 16:02:11 -0500

> "take" is at odds with long standing IETF BCPs.

Traditionally the IETF has considered security to be end-to-end security or
nothing. Protecting against meta-data and traffic analysis attacks has been
considered to be too hard and too little return on investment.

Whether or not we agreed with the past status quo (I did not), it was a
product of the constraints and security requirements that existed
pre-Snowden. One of the effects of Snowden is that there are more people
willing to commit more resources to solving security problems. So even if
you are not surprised by the Snowden releases, the fact that the knowledge
is out there changes what is possible.

Before Snowden I thought that any attempt to deploy end-to-end email
security was futile. After Snowden I think that we have another chance.
Which is rather strange given that it is not a protection against meta or
traffic analysis. But that is just a consequence of the fact that I can
build on twenty years of work and a ten year base of deployed code that is
95% right.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Dec 2013 10:26:42 +1300

> "take" is at odds with long standing IETF BCPs.

And just to repeat an earlier discussion:

MTI != MTIMC != MTEBD != MTD

Mandatory to Implement
Mandatory to Implement and Make Configurable
Mandatory to Enable by Default.
Mandatory to Deploy

These distinctions matter. The first three are requirements on
coders and vendors, that we can include in IETF standards.
The last one is a requirement on operators, who will do what
they think best or what local laws force them to do.

    Brian

---

From: <[email-masked]>
Date: Sun, 8 Dec 2013 21:46:13 +0000

>MTI security is what's called for by BCP 61.

...only for standards-track protocols.

And that document asks 'is encryption  a MUST' and sensibly answers 'no'
as far as confidentiality goes. draft-farrell-perpass-attack goes beyond
that to insist on confidentiality everywhere.

So, your take on MTI seems far far broader than that in BCP 61.

[..]

>this is also a fine 1990's era argument.

DTNRG (late 2000s, yet still persisting as a group as e.g. the TCP
convergence layer isn't published yet) is a much more recent example
of this.

Damn right.

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

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sun, 8 Dec 2013 22:04:53 +0000

Sent from my iPad

> On 8 Dec 2013, at 21:27, "Brian E Carpenter" <[email-masked]> wrote:
> 

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.

-Stewart

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 08 Dec 2013 22:07:12 +0000

Lloyd, I think we have expressed our positions here. I fear no additional views from my side will change your positions on that topic. You are just not a big fan of security.  

If I have a wrong impression drop me a note and we do a quick off-list chat. 

Ciao
Hannes

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 08 Dec 2013 23:16:40 +0100

* Hannes Tschofenig wrote:
>You are just not a big fan of security.  

That's how we got pervasive surveillance.
-- 
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: <[email-masked]>
Date: Mon, 9 Dec 2013 00:37:01 +0000

Hannes,

Au contraire. I like security. I recognise the need for security, and am glad it exists.

I'm just not a big fan of people who demand security where it is not needed, and who prioritise security above all other aspects of protocol design, which are dismissed as unimportant and are neglected as a result.

Transport suffers as a result.

Lloyd Wood

________________________________________
From: Hannes Tschofenig [[email-masked]]
Sent: 08 December 2013 22:07
To: Wood L  Dr (Electronic Eng); [email-masked]
Cc: [email-masked]
Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Ciao
Hannes

---

From: t.p. <[email-masked]>
Date: Tue, 10 Dec 2013 10:35:51 +0000

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, December 08, 2013 9:26 PM
> they think best or what local laws force them to do.

Absolutely; and this is something that the I-D under discussion seems to
ignore.

Also, quite often our RFC specify that a particular feature should be
controllable, that there should be a 'button' to allow it to be disabled
or enabled, which I think again needs promoting.  (If I had the option
to turn off encryption when submitting this e-mail to my MX, I would do
it most of the time - it is nothing but hassle and, of course, it is
'end to almost-nowhere' and so seems to me to add nothing by way of
privacy).

Tom Petch

---

From: t.p. <[email-masked]>
Date: Tue, 10 Dec 2013 10:14:43 +0000

----- Original Message -----
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, December 08, 2013 10:07 PM

> Lloyd, I think we have expressed our positions here. I fear no
additional views from my side will change your positions on that topic.
You are just not a big fan of security.

<tp>
Lest it be thought that the same applies to me, let it be clear that I
am a MASSIVE fan of security, security being authentication,
authentication and authentication (with integrity not far behind, and
encryption, well you know my views on that).

It is phishing and its derivatives that I see as most damaging to the
general users of the Internet, such as I; and every time I hear the
media say, 'look for the padlock on the screen' I think 'another bunches
of lambs being led to the slaughter'. And I think that the IETF is not
doing what it should when it does not pay more attention to that.  What
did we do with "draft-hartman-webauth-phishing-05.txt"?

Tom Petch

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Dec 2013 14:31:43 +0200

> I'm just not a big fan of people who demand security where it is not needed, and who prioritise security above all other aspects of protocol design, which are dismissed as unimportant and are negle…

Perhaps it might be easier to discuss this if we all recognised that it is a question of tradeoffs. (But as Phillip correctly noted, the world changes, perceptions changes, new information comes available, and today's tradeoffs may be different from yesterdays.)

Jari

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Dec 2013 13:40:51 +0100

On 12/10/13 1:31 PM, Jari Arkko wrote:
> Perhaps it might be easier to discuss this if we all recognised that
> it is a question of tradeoffs.

Precisely, Jari.  That's what engineers do, particularly in WGs.  That
notion should be better represented in the document.

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Dec 2013 14:47:08 +0200

Stewart,

> lower end of the franchise looks like.

You bring up a good point. And that is very important. The world of devices may be more significant for Internet privacy than the world of browsers and computers.

That being said, it is not always clear that small devises imply no security is possible. My day job crypto team has worked on Arduinos, for instance. And many of my friends who are in the devices business have been using 32 bit CPUs for a while now because they are more easily available and/or cheaper. All this reminds me also of my work fifteen years ago on optimising various protocols in cellular devices, only to find out that couple of years later most devices were capable of running 3D FPS games. Recently some of my colleagues did an analysis of the energy consumption in today's small CPU platforms, and found that wireless transmission/reception far outweighs any other activity, including crypto. But there are indeed challenges in security of the device world. I'd suggest they are mostly in the category of provisioning models (e.g., configuration) or architecture (e.g., transport vs. other types of security). More work needed...

In any case, the document said "where possible", and I think it is important to keep that distinction. Not all things are possible, and some possible things are not possible in all platforms.

Jari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Dec 2013 07:50:31 -0500

On Tue, Dec 10, 2013 at 7:31 AM, Jari Arkko <[email-masked]> wrote:

> > I'm just not a big fan of people who demand security where it is not
> needed, and who prioritise security above all other aspects of protocol
> design, which are dismissed as unimportant and are neglected as a result.
>
> Perhaps it might be easier to discuss this if we all recognised that it is
> a question of tradeoffs. (But as Phillip correctly noted, the world
> changes, perceptions changes, new information comes available, and today's
> tradeoffs may be different from yesterdays.)
>

What else do we really need to do?

I don't see reducing the load time of a HTTP page by a few milliseconds to
be a higher priority, though the browser providers have always disagreed
with me on that.

The real tradeoff comes in implementation quality. Most IETF security
protocols have been considered to be checklist items. They are features
that are supported only to the extent necessary to claim support. So
Windows and Mac both support IPSEC VPN but the native implementation has a
rubbish user interface.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Dec 2013 07:56:58 -0500

On Tue, Dec 10, 2013 at 7:47 AM, Jari Arkko <[email-masked]> wrote:

> You bring up a good point. And that is very important. The world of
> devices may be more significant for Internet privacy than the world of
> browsers and computers.
>
> That being said, it is not always clear that small devises imply no
> security is possible. My day job crypto team has worked on Arduinos, for
> instance. And many of my friends who are in the devices business have been
> using 32 bit CPUs for a while now because they are more easily available
> and/or cheaper. All this reminds me also of my work fifteen years ago on
> optimising various protocols in cellular devices, only to find out that
> couple of years later most devices were capable of running 3D FPS games.
> Recently some of my colleagues did an analysis of the energy consumption in
> today's small CPU platforms, and found that wireless transmission/reception
> far outweighs any other activity, including crypto. But there are indeed
> challenges in security of the device world. I'd suggest they are mostly in
> the category of provisioning models (e.g., configuration) or architecture
> (e.g., transport vs. other types of security). More work needed...

The problem of low power is that one of the corollaries of Moore's law is
that the low performance device gets cheaper and is added to more things.
So the number of low performance devices goes up over time, not down.

Another constraint is the complete lack of user affordances. The best place
to put network control is in the LED light bulb. But that does not have any
buttons (and it is in the ceiling anyway).

We don't need to send many messages to such devices and we don't
necessarily need to send them over wireless. But we do need to make sure
that any messages we do send are not ambiguous. There is a home automation
standard called X10 that is complete rubbish because it allows anyone in
the same neighborhood to observe and send commands.

---

From: <[email-masked]>
Date: Tue, 10 Dec 2013 13:45:03 +0000

To recognise and choose tradeoffs, a broad engineering perspective is needed. My point here is that those with a security focus often simply do not recognise, acknowledge or countenance tradeoffs. The goal of perfecting security does not allow it.

An example: Try discussing MD5's use in a reliability context fior error detection with security types. You'll hear that MD5 is insecure, that it's 'broken', that it shouldn't be used, and that's that. Which is why the checksum text now exists in RFC6151, as a careful rejoinder to that. (Yet oddly you don't see anyone complaining about the collisions in CRC32 and the security weaknesses of that.... But knowing about Hamming etc is mere engineering, and beneath notice.)

Viewing everything through a security lens doomed DTNRG work, and making security the ultimate arbiter of any protocol, design, as it was in DTNRG, will ultimately destroy any future IETF transport work. The process involved will be simply unsurmountable, the arguments unbearable.

Lloyd Wood

________________________________________
From: Jari Arkko [[email-masked]]
Sent: 10 December 2013 12:31
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Jari