Subject: [Gen-art] Gen-Art telechat review of draft-farrell-perpass-attack-04

From: Scott Brim <[email-masked]>
Date: Sat, 18 Jan 2014 15:41:24 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-farrell-perpass-attack-04
Reviewer: Scott Brim
Review Date: 2014-01-18
IETF LC End Date: 2013-12-31
IESG Telechat date: (if known): 2014-01-23

Summary: Ready

Major issues: none

Minor issues: none

Nits/editorial comments: There are editorial changes I could suggest, but
it's good enough.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Jan 2014 22:53:12 +0200

Thanks for your review, Scott.

Jari

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Jan 2014 09:30:06 +0100

Jari,

I oppose changes made to the document in the last round as stated
below.  If they remain, I would urge publication as Informational and
not BCP:

>    In particular, architectural decisions, including which existing
>    technology is re-used, may significantly impact the vulnerability of
>    a protocol to PM.  Those developing IETF specifications therefore
>    need to consider mitigating PM when making these architectural
>    decisions and be prepared to justify their decisions.  Getting
>    adequate, early review of architectural decisions including whether
>    appropriate mitigation of PM can be made is important.  Revisiting
>    these architectural decisions late in the process is very costly.

In the fact of a lack of common understanding regarding the threat, this
text can subject a working group to abuse and confusion.  This isn't
theoretical, as it has happened in the past that working group chairs
and area directors in particular have derailed efforts, setting
standardization and deployment of useful technology back years, and this
wasn't that long ago.

Let's make this discussion concrete with a few examples: the
implications may be that a working group chair or any participant
(although chairs are in a very good position to cause damage) could
insist that DHCP not be used to carry new attributes because there is no
common understanding of the scope of remediation that will be required. 
Before certain ADs roll their eyes, the discussion gets derailed as follows:

>> I propose the following DHCP option to configure my new frob.
<< But DHCP is transmitted in the clear.  Please justify this decision.
(or worse) << and by the way here is my very heavy weight alternative
that requires a valid cert chain
>> It's meant for the local wire.
<< But we don't know the scope of the attack.
...
...
>> Nevermind, I'll just use a vendor extension.  Goodbye.

Rinse and repeat with any other protocol that allows extensions.

It is fair to say that we should consider this threat at an
architectural level.  It's fair (albeit a truism) that finding design
flaws earlier in the process rather than later is less costly
(ENG-101).  Justification language like the above, however, is likely to
actively impede the IETF, as these sorts of things have in the past.

Eliot

---

From: <[email-masked]>
Date: Sun, 19 Jan 2014 08:40:47 +0000

+1. if you must publish this, publish as informational, as previous referenced security docs have been.

A doc that says 'you just haven't considered security enough' is not specifying the details or scope of a best current practice that can be sensibly followed.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Eliot Lear [[email-masked]]
Sent: 19 January 2014 08:30
To: Jari Arkko; Scott Brim
Cc: gen-art; IETF discussion list; [email-masked]
Subject: Re: Gen-Art telechat review of draft-farrell-perpass-attack-04

Jari,

I oppose changes made to the document in the last round as stated below.  If they remain, I would urge publication as Informational and not BCP:

In the fact of a lack of common understanding regarding the threat, this text can subject a working group to abuse and confusion.  This isn't theoretical, as it has happened in the past that working group chairs and area directors in particular have derailed efforts, setting standardization and deployment of useful technology back years, and this wasn't that long ago.

<< But DHCP is transmitted in the clear.  Please justify this decision.
(or worse) << and by the way here is my very heavy weight alternative that requires a valid cert chain

It is fair to say that we should consider this threat at an architectural level.  It's fair (albeit a truism) that finding design flaws earlier in the process rather than later is less costly (ENG-101).  Justification language like the above, however, is likely to actively impede the IETF, as these sorts of things have in the past.

Eliot

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sun, 19 Jan 2014 18:17:22 +0000

I share these concern.

Stewart

Sent from my iPad

> On 19 Jan 2014, at 08:30, "Eliot Lear" <[email-masked]> wrote:
> 
> Jari,
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 19 Jan 2014 18:54:41 +0000

>>    these architectural decisions late in the process is very costly.

I'm not particularly fussed if this is included or not. I'm ok with
Jari and/or the IESG figuring it out however they do.

> standardization and deployment of useful technology back years, and this

To be honest that seems both overblown and unjustified to me.
I'm also entirely unconvinced by the example below and by your
analysis of how text that says nothing much new is somehow at
the same time horribly threatening. 'Abuse' and setting things
back years and the rest seem to me to bear no relationship to
the text in question. Best I can guess is that your fear of
over-zealous ADs causes you to read this text in some way that I
can't figure out, but that argument has been had already for
earlier text which seems to me entirely as strong as this text.

And that's why I included this in -04, it seemed to have support
from others and consideration of architecture is reasonable
and your objection is afaics nothing to do with the text itself
and hence invalid.

But as I said, I'm fine with this being resolved either way.

Cheers,
S.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Jan 2014 11:47:28 -0800

> actively impede the IETF, as these sorts of things have in the past.

If I'm understanding this exchange, it hinges on the distinction between 
due consideration vs. appropriate design response.

Pressing to have work "consider" an issue early and thoughtfully makes 
sense for any topic that is as important as pervasive monitoring. 
Having IESG evaluation produce a blocking Discuss because an AD feels 
that the consideration was not sufficient or the resulting design flawed 
in terms of this issue is another matter.

The point I'm seeing Eliot make is that we don't have enough community 
understanding of the topic to be sure what constitutes appropriate 
design consideration.  So, in the face of such minimal community 
understanding, an AD's blocking progress would be whimsical at best.

Based on how new this topic is -- we don't even yet have stable and 
shared terminology for the problem space nor the solution space -- 
Eliot's concern isn't just valid, it's important.

We /do/ have a long track record of well-intentioned ADs asserting 
Discusses that are reasonable in the abstract but impractical for work 
in the IETF, especially when the topic is frankly still vague.

While the formal status of this document is relevant to the concern, the 
more important issue I see is our community sense that work going 
forward needs serious effort, but also an understanding that the basis 
for blocking specification needs to be extremely cautiously applied.

By way of trying to be practical about being practical, I'll suggest 
that any IESG blocks based on a concern about pervasive monitoring needs 
to reflect a consensus view of the IESG, not just the concern of a 
single AD....

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: <[email-masked]>
Date: Sun, 19 Jan 2014 21:34:28 +0000

> the text in question.

Stephen,

you might recall interrupting a couple of early presentations we
made on Saratoga to raise a (in hindsight pretty much spurious
and irrelevant) security issue. We could see that you would block
any further work there, and we moved Saratoga away from DTNRG.

DTNRG has since produced a security protocol, rather than
exploring the DTN problem space. It has, in my opinion, set
DTN research back years. DTNRG considered security at
every point.

I view this as an early example of Eliot's doubts.
If you'd had this document then, you'd be pointing at that as well.

The concern is justified. Raise the 'but it's not secure! It's
snoopable!' cry too much, and watch work either die in process,
or leave the IETF.

(Perpass still isn't a working group, is it?)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 19 January 2014 18:54
To: Eliot Lear; Jari Arkko; Scott Brim
Cc: gen-art; IETF discussion list; [email-masked]
Subject: Re: Gen-Art telechat review of draft-farrell-perpass-attack-04

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 20 Jan 2014 00:48:50 +0000

> Rinse and repeat with any other protocol that allows extensions.

That’s a very practical concern. If standard solutions are too hard to develop, then products will use proprietary solutions instead, and we will not have won much defense against pervasive monitoring.

I personally agree with the general idea that new developments should consider PM as part of the threat model. But Elliot makes a good point. In practice, the good reviews don’t stop at negative advice, “don’t do this because the spooks will snoop.” The better reviews go on with “do this instead, it is almost as easy to use and it provides much better privacy.”

It would be interesting to list the specific patterns that are most likely to trigger the “bad because of PM” comments, and to develop secure alternatives. From what I see, there seems to be two big offenders, logs and configuration. So maybe we should develop a simple way to anonymize logs, and a secure way to get configuration data…

-- Christian Huitema

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Jan 2014 16:38:41 -0500

I think that consideration of perpass at the architectural  level, being
prepared to justify decisions, and seeking adequate review of those
decision early enough to make changes if we're wrong are critical to
this document.
strongly object to publication of this document without that.

I value integrity and honesty very highly and am feel sick when I think
about claiming to the world that we're going to address perpass
mitigations without being willing to commit to ourselves  to do the
architectural work.
You cannot simply  take a protocol and mitigate these sorts of issues.
Many of our existing technologies leak a lot of information to
attackers.
One of the most important decisions when we start work on new protocols
in terms of perpass mitigation will be what building blocks we use.

If we're not willing to commit to having those discussions up front,
reviewing them and when questions arise during that review , I don't
think we're being truthful or acting with integrity if we claim that
we're mittigating perpass threats.

I'd much rather us be honest that we're not willing to do what it takes
to deal with perpass threats than to claim to try and mitigate them with
a solution that I think will be unsuccessful.

I do understand being concerned and worried that an AD would block
something late in the process because of bad architecture.
If the architecture was appropriately reviewed, I think that's the right
wrong approach.  I'd support language making that more clear.
If the architecture was inadequately reviewed, I strongly feel  that
should be handled like any process problem.  Some process problems are
blocking; some cases of inadequate review of an architecture also should
be blocking.
Yes, some of that is subjective and needs to be argued by the IESG and
community if there is conflict.

---

From: Scott Brim <[email-masked]>
Date: Tue, 21 Jan 2014 17:26:30 -0500

Sam: I believe that all you ask is still there.  We will consider PM at
architecture time, and anyone can contribute. We'll take it seriously.
What's missing is the requirement to demonstrate that you have covered all
the issues, to an unknown level.  Essentially this is how we work already.

Scott

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Jan 2014 14:55:42 -0800

On 1/21/2014 1:38 PM, Sam Hartman wrote:
> decision
...
> mitigations without being willing to commit to ourselves  to do the

Sam,

Consider the level of activity on this topic that is already happening 
in the IETF, as well as the nature of this initial document.  I'll 
suggest that that's the most important demonstration of organizational 
commitment.

The document in question marks that commitment, but it needs to be 
careful not to mark it beyond our current capabilities.

In particular please point me/us to established consensus documents that 
define the problem space, the solution space and the architectural 
choices appropriate to this topic.  I'm not aware of any, but perhaps I 
missed them.

Absent established documents on this topic, "justifying" is only 
reasonable in terms of demonstrating thoughtfulness, not demonstrating 
that the choices are "correct".  Yet a term like "justify" encourages 
this latter expectations.   the view that we have far more community 
clue about this topic than we currently have.

d/