Re: Last call comments: draft-farrell-perpass-attack

Personally, I think all (new) IETF documents need a greater review in 
regards to their ethical and moral impact on society. But I don't see 
a solution other than to note that its been considered.
In my strong opinion, no doubt, there has been a far greater conflict 
of interest influence with fast tracking production going on. Without 
a doubt, a greater filtering of the concerns and input and the current 
leaders are no longer shy on bringing down the hammer on folks who 
have issues to the extent of accusing them of WG disruption. (See all 
the new behavior control drafts).   I have no real problem with this 
near form of rubber stamping as long at the ethical issues and 
conflict of interest are reduced.
To me, this draft is not entirely clear in what it seeks. It certainly 
highlights that pervasive monitoring is  a problem, but we always knew 
it was a problem since the annals of electronic communications.  To 
developers who help enabled this market, we already new it was all 
possible. The difference was the moral and ethical engineering, the 
taboos, the can of worms, engineers did not wish to introduce.
That has changed. For whatever many security, national and BI reasons, 
the market is leveraging the long time availability of publicly 
exposed information over the wire, but now to a greater extent, even 
private information in FULL DUPLEX MODE!
One current example which has people worked up recently in Facebook in 
regards to their "pervasive monitoring" of your Facebook user draft 
comments input before it is "officially" sent!!
http://www.slate.com/articles/technology/future_tense/2013/12/facebook_self_censorship_what_happens_to_the_posts_you_don_t_publish.html

What can this draft "teach" the designers of such software which was 
always possible but considered an industry taboo?
I don't think any technical steps can be taking here by any WG for 
future or current proposals on the table.  This is purely about morals 
and ethics.
Can you imagine if all the MUAs vendors deciding to follow suit and 
begin to leverage your draft email replies to this IETF discussion group!?
--
HLS

On 12/13/2013 6:49 PM, Sam Hartman wrote:
> Hi.
> I strongly support the consensus statements that were the sense of the
> room at the IETF 88 technical plenary.
> I strongly support publication of a document like this, but I believe
> this document should provide more guidance before publication.
>
>
> We have a history of publishing vaguely worded security BCPs that are
> really hard on our area directors and chairs.  As an AD, I found
> aspects of RFC 3352, BCP 61 and RFC 4107 very challenging.
> The big questions tended to surround protocols already in progress and
> architectural re-use.
>
> Let's not do that again.
>
> Protocols already in progress  is a fairly obvious problem.  I don't
> think we want Stephen and Sean to hold a DISCUSS on every document on
> the telechat following approval of this BCP because none of them explain
> how they mitigate pervasive monitoring.  Stephen and Sean wouldn't do
> something that ridiculous, but I believe they and the community could
> use better guidance than "use good judgment."  I know as a document
> author, chair and former AD I sure could.
>
> my recommendation is that protocols with no significant solution work
> accepted by a WG need to address this BCP the same way new protocols
> would.  Protocols with significant solution work within a WG need to
> address this  BCP to the extent that doing so is consistent with the
> existing work antd doesn't  involve reopening decisions that would
> otherwise be closed or revisiting earlier stages in the process that
> would not otherwise be revisited.  So, if you haven't decided on your
> security mechanism yet, take this into account.  If you're working on
> security considerations but your protocol is basically done, write up
> how well you did but don't revisit things.  If you're in last call, move
> on as usual.
>
> The architectural re-use question is harder to explain.  Imagine you're
> desiging something new.  You could use enum-like things or some other
> directory.  It would be convenient to use DNS because similar
> technologies you care about use DNS.  If you use DNS, then people can
> more easily monitor the queries to your service.  How much do you need
> to consider pervasive monitoring in your technology choice.  We've had
> this sort of thing come up lots with previous security BCPs; I most
> especially remember being told by PCE that they had chosen not to follow
> RFC 4107 because they wanted to be like other routing protocols and use
> TCP-AO even though it doesn't provide key management.
>
> The issue of architecture re-use is important to discuss in the
> community because it significantly affects how much impact this BCP will
> have.  If we say "use good judgment," and nothing more, then we're
> basically leaving it entirely up to the WGs, because cross-area-review
> time is really late for telling someone they need a new fundamental
> technology.  Obviously the WG will have significant impact on this, but
> I think if we provide useful guidance here it can really help.  My
> personal preference is that this BCP should impact future architectural
> choices more than RFC 4107 has managed to but that architectural re-use
> is quite important.
>
> A related issue is how to treat extensions to existing  protocols.
> Again we've had a lot of heart-ache from not specifying that.
>
> I think it is important for the community to receive guidance on these
> issues.  I think it would be fine for this BCP to delegate that
> guidance.  I'd support a paragraph describing each issue plus a
> paragraph saying that the IESG would provide guidance if the IESG would
> be willing to do that.  Obviously that would mean we're trusting the
> IESG to make that decision; I'd be happy to do that.  I'd also be happy
> to work on guidance to be included in the BCP on these issues.
>
> I do not support the document remaining silent on these issues.
>
> Please, whatever you do, remove section 3 on the process note.
> As it stands, it reads as follows:
>
> * We're unable to find a way for the IESG and IAB to publish a document
>    together
>
> * We really wish the IESG and IAB could publish a document together bbut
>    reluctantly being unable to do that we'll settle for a community
>    consensus document.
>
> If you must say something how about:
> In the past, architectural statements of this sort have been published
> as joint  products of the IESG and IAB.  This document represents the
> community consensus of the IETF and was published in accordance with the
> processes in affect at time of publication.
>
> In particular, I think a community statement of the whole community is
> stronger than a joint IAB/IESG work product.  I'd hope that the IESG and
> IAB would support the team and say that "Hey, we're part of the
> community, and a community consensus is how we present really strong
> statements."
>
> The IAB also has an ISOC role beyond the IETF.  If they want to
> emphasize support in that role, they could release a statement on their
> own making that clear.  However I think it would be more powerful if the
> IAB worked with ISOC to release such a statement and was included in
> that statement.
>
> I'm also still sputtering at the idea that our leadership cannot find a
> way within the current process for the IESG and IAB to publish a
> document together ifg they wanted to.  I don't think that would be
> desirable in this instance.  We've changed and there's more focus on the
> community than there was in the RFC 1984 days.  However, I hope that if
> it were the right thing to do our leadership could work together and
> publish a joint document.  The current text really sounds like you
> believe you couldn't.  Let's try and be better team players than that.
>
> In response to other last call comments:
>
> I do not support the idea of taking the time to figure out how each WG
> is impacted by this document.
>
> I understand the desire to figure out whether we have consensus that
> pervasive monitoring is a threat quickly.  If we find that we have some
> open issues to resolve like the ones I bring up, but that we have
> consensus on the basic point, we have a quick way forward.  Jari could
> announce that the consensus of the IETF 88 plenary has been confirmed on
> the list and we could move forward.  It's rare that the IETF acts in
> plenary, but not rare that we make consensus calls about the big points
> in documents while details are still open.