Subject: 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: Jari Arkko <[email-masked]>
Date: Sun, 19 Jan 2014 23:21:18 +0200

Thanks for this, Dave. 

Here are some thoughts from my perspective. I'm not sure I agree that we've seen pattern of "well-intentioned but impractical" blocking Discusses from the IESG, but I think we've seen some cases. I know I have erred at times :-) But I think both the IETF and even me have learned over the years to do this a bit better. And we need to continue to watch for this, or perhaps even come up with better processes to defend against it.

I'd like to separate this phenomena a bit from the current draft, however. The basic problem is that the discuss criteria [1] that the IESG currently lives by states technical flaws are a valid reason for a Discuss. And that "technical flaw" isn't defined in any manner. It is not limited to BCP guidance, for instance. And even when there is a BCP, it almost never the case that there are rules that can be followed blindly. Unfortunately, the beauty (or flaw) is in the eye of the beholder. The raised concerned can range from ridiculous to Internet damaging. Say, from trivial design choices to totally missing congestion control in a situation where it would have been necessary. It is difficult to devise hard rules about what constitutes a flaw and a valid Discuss. And if it were possible, I'd have some more work for Henrik and a quick IESG re-org in the works :-) For now, we are stuck with using good judgement. Take that congestion control example - we often have to figure out if a particular concern applies in a specific setting. Congestion. Or security - not all security functions are relevant at all layers, for instance. And people might not agree where a specific case belongs to. One person may think a change was uncalled for where another might think it was crucial for the operation of the Internet.

And when there is an argument, the way we pretty much have to deal with these cases is through (1) discussion (2) community consensus and (3) complaints, appeals, nomcom, and recalls if nothing else helps.

FWIW, independent of this discussion I have personally reached the conclusion that the IETF needs to be more careful about anyone's personal opinion affecting the outcome. No one's personal preference should prevent informed consensus opinion from going forward. The first two items in the discuss non-criteria list are related to this, but could perhaps be stronger (they have some caveats). My recommended process for discussing something that IETF has informed consensus over is to take it up with the IETF and see what consensus comes out of it, rather than (say) an AD saying we need to do this or else.

Jari

[1] http://www.ietf.org/iesg/statement/discuss-criteria.html

---

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: Dave Crocker <[email-masked]>
Date: Sun, 19 Jan 2014 16:56:09 -0800

On 1/19/2014 4:48 PM, Christian Huitema wrote:
> 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…

What an excellent point.  It highlights something we probably should 
pursue explicitly and aggressively:

    1.  Working on learning how to analyze PM concerns in specifications

    2.  Learning how to formulate PM defenses in designs

    3.  Diligently documenting what we learn

That is, we need to treat this topic as something we are all still 
developing an understanding of -- both the problem and its mitigation -- 
and therefore need to collaborate on.

Methinks these are two wikis we need...

d/

---

From: <[email-masked]>
Date: Mon, 20 Jan 2014 02:35:22 +0000

And when you can answer those three points, you'll have a BCP.

Until then, this is informational.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Dave Crocker [[email-masked]]
Sent: 20 January 2014 00:56
To: Christian Huitema; Eliot Lear; Jari Arkko
Cc: IETF discussion list
Subject: Re: Gen-Art telechat review of draft-farrell-perpass-attack-04

d/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jan 2014 07:14:20 +0100

Jari,

On 1/19/14, 10:21 PM, Jari Arkko wrote:
> But I think both the IETF and even me have learned over the years to do this a bit better. And we need to continue to watch for this, or perhaps even come up with better processes to defend against it.

I'm certain you've learned, Jari, although I do find myself repeating
one particular point:

Organizations DON'T learn; (some) people do.  We can build processes
into organizations that help us to either not repeat the mistakes we or
others have made, or to exacerbate matters.  In my experience it is
usually both, by the way, and you just hope that on the whole you've
made matters better.

Those of us who have learned, recognize the danger in the proposed text
to wedge a group, not simply because it could seemingly be used as a
sledgehammer as my earlier anecdote demonstrated (and I modified that
only slightly from what happened in ISMS), but because in this specific
circumstance we do not have a handle on the problem of pervasive
surveillance – yet.

What do I mean when I make that statement?  It deserves justification
itself ;-)

We have in draft-farrell-perpass-attack a definition of what pervasive
surveillance is to us.  We do not yet understand, however, what our own
capabilities and limitations are in defending against it.  By negative
proof, had we this understanding the IAB would not be holding a joint
workshop with the W3C to gain it.  There is barely even a framework by
which we talk about pervasive surveillance.  We know that encrypting
data between the end user and a service somewhere off in the Internet
*may* provide some confidentiality, depending on the strength of the
encryption and a host of other factors.  We have some understanding of
the performance impact of encryption.

On the other hand, there is everyone's favorite catch-phrase:
meta-data.  That is, the 5-tuple in packets, the timing associated with
transmission and delivery, their size, and reasonable *engineering*
assumptions to make about where people can and will monitor.  We also
only have limited understanding of the performance impact on any
mitigations to avoid masking these qualities.

We also have but a limited understanding of when it is valuable to
encrypt and when such encryption would be negated by factors that we
find impractical to eliminate, such as traffic and timing attacks or
when the existence of later communication itself reveals the same
information (e.g., DNS queries followed by a connect()).

We have a limited understanding of how much of pervasive surveillance
should be addressed at the upper layers versus the lower layers. 
Encrypting once has a cost.  Encrypting several times has several times
that cost.  Encrypting end-to-end using the mechanisms we have today may
itself facilitate collection of metadata.

It should not be surprising that we don't know as much as we would like,
as we are still at the beginning of this process, just as we began the
process for security considerations so many years ago.  Right now our
job is to figure all of this out.  By "our" I mean that we all need to
be thinking about this problem, identifying risks, and discussing ways
to reduce them, while exposing what tradeoffs there are.  That's why I
like *most* of Stephen's draft (all of it but one paragraph, in fact),
and why I'm glad Stephen is chairing the workshop in London.

And while I'm glad you understand how ADs can go too far, you also have
to recognize that we have been down this path before with others, and it
has been very rocky.  Working group chairs are in a fine position to
make a muddle of things, and we (I speak of myself as well) do an even
better job of muddling when there is not community understanding of the
above problems.

And this brings us to Sam's proposed text:

>    Those developing IETF specifications therefore
>    decisions and be prepared to justify their decisions.

We don't have the people or knowledge in place to reasonably evaluate
such justifications at this point.  The person who proposed this text
proposed an example that may well have been in error.  That is no fault
of his, really, because we are all learning.  But let's not encourage
huge architectural swings when we don't yet have a handle on what advice
should be given.  Discussion and careful consideration are important
now.  Getting ideas out there is good.  Testing them is great! Nailing
some of the obvious bits, like asking why certain information is
exposed, is fantastic.  Discussion about protocol selection is excellent.

But the words that are quoted are stronger than that.  They can be used
by chairs and others to shift the burden onto the proponent of a
proposal when we have no shared understanding of what needs to be
addressed.  That's too high a bar and will lead to well-intentioned –
but wrong – engineering decisions.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jan 2014 14:55:40 +0100

So... having written a bunch of stuff, someone has suggested to me an
alternative compromise offlist, as follows:

OLD:

NEW:

   decisions.  Getting

I can live with this, largely because everything there is true at the
general level. We're all going to learn to provide more specific advice
than this, however.  As I wrote, I am hoping that the STRING workshop
will help us make some headway.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jan 2014 14:57:28 +0100

Aiming for the top of the Narten list for the week...

> will help us make some headway.

s/STRING/STRINT/

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2014 15:59:03 +0200

This would work for me. Thanks, Eliot.

Jari

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Jan 2014 10:14:36 -0500

>> actively impede the IETF, as these sorts of things have in the past.
As one of the folks who suggested "address" vs. "consider" I now recant.

I am satisfied with "consider."

if anyone cares :-).

Steve

---

From: Scott Brim <[email-masked]>
Date: Mon, 20 Jan 2014 10:25:36 -0500

...
>    decisions.  Getting

wfm

> the STRING workshop

I believe your daughter is just the right age for the delightful
"Letitia Rabbit's String Song", if you can find it.  Happy String!

Scott

---

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/

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jan 2014 18:02:08 -0500

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> Sam, FWIW my view is pretty much what Dave and Scott noted. I
    Jari> don't think the change weakens the draft's message: We'll take
    Jari> the issue seriously.

I disagree for the following reasons.
When we remove text saying that WGs need to be able to justify  their
decisions, we're saying that we do not have consensus on that statement.

If we do not have agreement that WGs should be able to justify their
choices with regard to perpass mitigation, then I think that we are not
actually  going to do what is necessary to approach the issue.

Here are concrete examples of what I expect to be able to do:

* I should be able to ask NVO3 to explain why they chose an architecture
  that either does or does not support encryption of data plane traffic
  while reviewing that architecture.

* If we were doing DDS/NAPTR work today I should be able to ask whether
  confidentiality is a requirement and if so why DNS is an appropriate
  substrate.

* If the working group I chair (kitten) were to actually work on an
  administration protocol to manifest our information model for
  Kerberos, I should be able to ask about privacy implications of that
  protocol and whether Kerberos is an appropriate substrate.

To me, by removing text that WGs need to be able to justify these sorts
of decisions we're saying that we don't have consensus that such
questions would need to be justified during a review.

If you think those are reasonable, then I'd strongly prefer to spend the
time to figure out what we actually mean.  Come up with text that makes
it sure that such questions are reasonable while ruling out the things
people are worried about.

If we do not think  that WGs should be required to justify these
positions, then I strongly object to a claim that we have chosen to
mitigate perpass attacks because I believe that claim is meaningless
without actually being able to get WGs to justify these decisions while
doing architectural review.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Jan 2014 08:29:56 +0100

>   confidentiality is a requirement and if so why DNS is an appropriate

And herein lies the problem.  It would depend on the record's
application, and how information was released that couldn't otherwise be
relatively easily gleaned.  Would you find that a sufficient answer? 
And what if you didn't?  Who should decide?  Nothing stops you from
asking the question now, by the way,  and we're already saying that
people should ask these sorts of questions and give serious
consideration to the matter.

And the example points to another problem.  We neither have a common
view of what the threat is or how best to mitigate it.  Therefore, *at
this moment in time*, how can we go any further without (a) possibly
addressing the wrong threat, and (b) causing inefficient or
inappropriate architectural changes?

My previous sentence more than implies, by the way, that this situation
is subject to change based on how we further our understanding of the
issue.  The draft also states that.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 Jan 2014 11:06:30 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot>    On 1/23/14, 12:02 AM, Sam Hartman wrote:
    Eliot> * If we were doing DDS/NAPTR work today I should be able to
    Eliot> ask whether confidentiality is a requirement and if so why
    Eliot> DNS is an appropriate substrate.

    Eliot>    And herein lies the problem.  It would depend on the
    Eliot> record's application, and how information was released that
    Eliot> couldn't otherwise be relatively easily gleaned.  Would you
    Eliot> find that a sufficient answer?  And what if you didn't?  Who
    Eliot> should decide?  

I find it a sufficient answer; I'm not actually sure I agree with it but
it's definitely the kind of answer I'm looking for.
Whether I agree with the answer doesn't matter for a hypothetical.

Who decides?
Our standard process applies for figuring out whether we as a community
have decided something--the IETF rough consensus process.
The specific details of that process are kind of complex, but I think we
both agree to a fairly strong approximation what that process is.  We
probably disagree on details about corner cases that don't come up
often.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Jan 2014 22:48:41 +0000

Sam,

FWIW my view is pretty much what Dave and Scott noted. I don't think the change weakens the draft's message: We'll take the issue seriously.

Jari

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Jan 2014 15:43:14 -0500

--On Wednesday, January 22, 2014 18:02 -0500 Sam Hartman
<[email-masked]> wrote:

>...
> If you think those are reasonable, then I'd strongly prefer to
> spend the time to figure out what we actually mean.  Come up
> with text that makes it sure that such questions are
> reasonable while ruling out the things people are worried
> about.
> 
> If we do not think  that WGs should be required to justify
> these positions, then I strongly object to a claim that we
> have chosen to mitigate perpass attacks because I believe that
> claim is meaningless without actually being able to get WGs to
> justify these decisions while doing architectural review.

IMO, this lies nearly at the core of one of my fundamental
issues with the draft.  If we are looking to make a broad
statement of intent that is not actually actionable, then the
statement linked from the IETF home page as "Leading Engineers
Agree to Upgrade Standards to Improve Internet Privacy..." is
probably sufficient.   If someone wanted to republish that as an
Informational RFC, I'd hope that would not be controversial (if
it were, we have much deeper problems with this "perpass-attack"
draft).

On the other hand, if there is a real commitment to action, then
WGs have to be accountable for design decisions that do (or do
not) support the goal and be ready to explain their decisions,
even privacy-protecting ones that impose or increase costs to
performance, operations, or elsewhere.  And I would expect (not
merely fear) ADs to push back strongly on a WG that was
unwilling or unable to do that and expect Nomcoms to hold ADs
accountable if they did not enforce the intent of the rules.

It is not clear to me that the community is really willing to
make that commitment.  Fortunately, I'm lucky enough to not have
to make that call.  

But it seems to me that this document, especially with some of
the recently-proposed changes, is trying to simultaneously be 

	-- a general statement of principles that sounds good,
	encourages people to do good deeds wrt privacy and
	surveillance issues but doesn't represent a real,
	actionable, commitment by the IETF     and
	
	-- something far more substantial that actually changes
	the way we do things wrt this particular area.

I don't think it can be both.  And, if it is the latter, then
ADs who holding up a document with a DISCUSS or who try to force
a WG to more clearly justify its decisions are not being abusive
-- they are doing the job that the community has demanded of
them.   And that, IMO, is what is different from the various
notes that have said, more or less, "we don't need to worry
about ADs holding up documents and abusing the system because of
this draft because there are ample opportunities for abuse
already".  The concern is the AD who will say "just doing my job
and that document explicitly tells me that the community said
that was my job -- it isn't a judgment call whether or not it
is".    That is ok if it is what the community wants, but we
need to be careful what we wish for.

    john

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 Jan 2014 16:13:05 -0500

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> On the other hand, if there is a real commitment to action,
    John> then WGs have to be accountable for design decisions that do
    John> (or do not) support the goal and be ready to explain their
    John> decisions, even privacy-protecting ones that impose or
    John> increase costs to performance, operations, or elsewhere.  And
    John> I would expect (not merely fear) ADs to push back strongly on
    John> a WG that was unwilling or unable to do that and expect
    John> Nomcoms to hold ADs accountable if they did not enforce the
    John> intent of the rules.

Strongly agreed.
And if we don't have a community commitment to do that can we please be
honest with the world and tell everyone that when we look at the cost of
this issue it was something our community did not choose to pay?

    John> It is not clear to me that the community is really willing to
    John> make that commitment.  Fortunately, I'm lucky enough to not
    John> have to make that call.
I hope we are willing to make that commitment.

Note however that I do not want ADs pushing back at the end of the
process (unless WGs clearly failed to get adequate review of their
architectures up front.)

End-of-process security work is rarely all that productive.
You spend weeks or months fighting for little gain and for everyone
involved walking away with a sence of frustration and a diminished sense
of joy in the engineering challenges we face.

I want ADs to be pushing back in the early architecture phases.
Comments on early architecture drafts, and WG-decision-level appeals
filed early in the process are probably better tools for pushing back
on WGs that are not adequately considering privacy than late-stage
discuss positions requiring architectural change.

And as Eliot points out, the question of what balance in tradeoffs is
appropriate will evolve over time.  At the beginning if a WG does a good
job of considering something and you just don't like how they balanced
the issues, your only option is to start a broader discussion.  That's
how it should it be.  If community norms emerge, then there are tools
for applying those.

---

From: Scott Brim <[email-masked]>
Date: Thu, 23 Jan 2014 16:23:51 -0500

> this issue it was something our community did not choose to pay?

Being ready to explain decisions (or positions) is fine. The problem
was the word "justify". When do we know that a decision is justified?
Who decides? That's an undefined metric. WG decisions are explained,
and critiqued, all the time, by everyone.

Personally I hope we don't develop too "mature" a concept of what
we're including in pervasive monitoring, because we need to be open to
new ideas all the time. Therefore I hope we never develop criteria by
which a PM consideration could be "justified".

> process (unless WGs clearly failed to get adequate review of their

(Aside: That's circular -- unless the critique is based on new ideas
that emerged between WG last call and a telechat, then by definition a
late critique of an architectural issue means it failed to get
adequate review at the proper time.)

> discuss positions requiring architectural change.

Yes, and we encourage that with the paragraph as it is, without "justified".

> how it should it be.  If community norms emerge, then there are tools

Yes.

Do we have agreement?

Scott

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 Jan 2014 16:32:13 -0500

>>>>> "Scott" == Scott Brim <[email-masked]> writes:

    Scott> Being ready to explain decisions (or positions) is fine. The
    Scott> problem was the word "justify". When do we know that a
    Scott> decision is justified?  Who decides? That's an undefined
    Scott> metric. WG decisions are explained, and critiqued, all the
    Scott> time, by everyone.

I view justify and explain as synonyms in the text I proposed.
If people are OK with explain but not justify, I would support
publication of the document with that substitution.

I realize I may be in the rough regardless; I'm just stating my position
in case it is useful to those making a consensus call.

my problem is that by removing justify and not replacing it with
something like explain, then I see that as an active failure to get
consensus that a WG should have to (explain|justify--remember I don't
see a difference) the perpass implications of its architecture.
Without community agreement in favor of that, I think we have no
meaningful commitment to perpass mittigation.

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Jan 2014 05:35:34 -0500

--On Thursday, January 23, 2014 16:13 -0500 Sam Hartman
<[email-masked]> wrote:

>     John> On the other hand, if there is a real commitment to
> action,     John> then WGs have to be accountable for design
> decisions that do     John> (or do not) support the goal and
> be ready to explain their     John> decisions, even
> privacy-protecting ones that impose or     John> increase
> costs to performance, operations, or elsewhere.  And     John>
> I would expect (not merely fear) ADs to push back strongly on
>     John> a WG that was unwilling or unable to do that and
> expect     John> Nomcoms to hold ADs accountable if they did
> not enforce the     John> intent of the rules.
> 
> Strongly agreed.
> And if we don't have a community commitment to do that can we
> please be honest with the world and tell everyone that when we
> look at the cost of this issue it was something our community
> did not choose to pay?

Sam, 

I think we are in agreement but, to clarify one possible issue
about choosing to pay: my ongoing fear is that, no matter what
disclaimers are made during this discussion or in the document
itself, sooner or later someone will make, and get traction for,
the claim that, since we have a BCP that says "pervasive
monitoring/surveillance is bad and needs to be repelled" and no
BCP that says "performance is important", privacy is inherently
more important in protocol design.   I have no problem requiring
that a WG explain and justify choices that are not as
monitoring-resistant as is possible, but, were the community not
able to consider and accept such explanations (when they are
reasonable), I think we would be in big trouble.

FWIW, I slightly prefer "justify" to "explain" but, like you,
can live with "explain" if others have a strong preference in
that direction.

best,
   john