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

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Dec 2013 18:49:27 -0500

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.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 14 Dec 2013 13:57:27 +0000

Hi Sam,

> room at the IETF 88 technical plenary.

Cool.

> this document should provide more guidance before publication.

I think we disagree about that. More below.

> aspects of RFC 3352, BCP 61 and RFC 4107 very challenging.

Not sure. I've not found our BCP text problematic actually
and I'm not sure that vague wording is the cause of problems.
For example, bcp107/rfc4107 is pretty clear but often difficult
to apply if a WG actually aren't keen on doing the work for
automated key management - I don't think the wording is the
problem at all in cases I've seen.

> The big questions tended to surround protocols already in progress and

As you'll guess from the above I don't think we have that problem
with vaguely worded BCPs. And I don't think this one is vaguely
worded either - it is high level but not IMO vague.

> something that ridiculous, 

Absolutely. And I don't think any AD would or should do that.
As it happens, my experience over the last 3 years is that the
IESG have self-regulated in a way that would have addressed
this anyway. Many or maybe all new ADs (me included) seem to
start out being a bit too enthusiastic about some aspect of
the IETF but after a while, and sometimes a quiet chat or two,
we've all settled down to a better balance between making
progress and being picky. (Not sure if all authors would
agree mind you:-)

> but I believe they and the community could

I'm not sure of that, and I think that's the kernel of where
you and I perhaps disagree here. I don't believe we're in a
position where we can say much more than "use good judgement
and our existing knowledge of the attack and mitigations"
and we won't be in a position to do better for a few years
until we've seen what tends to work in terms of conforming
to the BCP *and getting deployed*.

I really don't want our reaction to Snowdonia to be a work
of fiction and that could happen if we do too much guessing
now.

I also don't want to see us wait years before we reduce the
real consensus that exists to words in an RFC. Doing the
most-significant-bit of that now is important IMO.

> to work on guidance to be included in the BCP on these issues.

I think the above is really useful and should feed into our
analysis of how to deal with the attack. For example, I'd like
to see it reflected in the threat-model document we've discussed.
I think text based on that would fit really well into a section
with a title like "what do I do about this for my protocol?"
maybe.

> I do not support the document remaining silent on these issues.

I'm afraid that that would lead to years of delay.

> * We're unable to find a way for the IESG and IAB to publish a document

That's accurate. Bit, isn't it;-)

>   reluctantly being unable to do that we'll settle for a community

That's not accurate though. In the IESG/IAB discussion on this,
after a bit of process-flapping, we quickly settled down on the
current plan and I think everyone recognised that this plan will
give a better outcome - IETF consensus being far better than
just IESG/IAB-say-foo.

> community, and a community consensus is how we present really strong

Fair point. Will think about re-wording to make the above clear.
I do think we need section 3 though to say why this is being
done differently from 1984 and 2804.

> IAB worked with ISOC to release such a statement and was included in

One for the IAB.

> believe you couldn't.  Let's try and be better team players than that.

I believe we couldn't and that that's silly. Folks who care more about
process than me would disagree that it's silly. I don't think anyone
is not being a team-player though. (And if this generates more mail,
please make it a separate thread since its tangential to this last
call.)

> is impacted by this document.

I agree.

> in documents while details are still open.

As I said above I think the more detailed guidance should not go in
here and will take a long time so we should approve the document and
move forward.

Thanks for the insightful comments,
Cheers,
S.

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 Dec 2013 11:49:30 -0500

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

---

From: SM <[email-masked]>
Date: Sat, 14 Dec 2013 12:45:01 -0800

Hi Sam,
>processes in affect at time of publication.

The above text sounds better than a process note.

>community, and a community consensus is how we present really strong

Yes.

>believe you couldn't.  Let's try and be better team players than that.

The text doesn't add much value to the document.  If the IAB feels 
strongly about being mentioned in the draft, it could suggest text 
for an IAB statement.  That statement could be added if the community 
agrees to it.

>in documents while details are still open.

There is a belief that a decision was taken at the IETF 88 
plenary.  I would describe the events as follows:

   (a) There was a talk about the tens of thousands of documents
      recently obtained from [removed].

   (b) Security Considerations up to now have the following implicit
       consideration:

         "Surveillance issues are not addressed in this memo"

   (c) The crowd was ready to vote "yes" (see title of draft).

   (d) The IAB Chair asked the question and the expected response was received.

   (e) There was a discussion in perpass.  That discussion was nuanced [1].

   (f) The IETF Chair suggested writing a RFC.

   (g) There were objections about the hums on the IETF discussion list.

   (h) There is currently a Last Call about an intended BCP relating 
to privacy.

The lesser effort is to publish a statement of intent as a RFC.  The 
problem with a statement of intent is: "what do you really mean when 
you say X?", or in other words, "how will this affect my draft or my 
business"?  This raises questions pertaining to architecture (re. 
message from Sam Hartman at 
http://www.ietf.org/mail-archive/web/ietf/current/msg84955.html 
).  It's a balancing act.  It isn't a significant problem if a 
working group can provide a rationale for its decisions.

Regards,
-sm

1. a subtle difference in or shade of meaning

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Dec 2013 11:39:28 +0000

On Dec 14, 2013, at 6:49 PM, Hector Santos <[email-masked]> wrote:

> Personally, I think all (new) IETF documents need a greater review in regards to their ethical and moral impact on society.

And to think that less than 9 years ago, RFC 4041 was considered an April Fool's RFC.

Yoav

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 Dec 2013 11:49:20 -0500

Hi Yoav,

> And to think that less than 9 years ago, RFC 4041 was considered an April Fool's RFC.

Its a new normal, I suppose. RFC2821 once believed that "an arrogant 
user" was a small email problem:

    7.1.  Mail Security and Spoofing

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail.

Its update, RFC5321, still believes its a small problem but the user 
is no longer arrogant:

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against a user who is trying to fake mail.

We understand why it was done, but really, how silly was all that to 
begin with!? This (spoofing potential) was a known issue since RFC821 
and it predated with other mail networking protocols was well!

The mindset does need to change.

Of course, the dilemma is how does the IETF community get involved in 
the growth of applications increasing leverage data that was once 
considered private or out of bounds for transmission?  How does it 
provide its input?

Good example, did Apple open a can of worms, "Pandora's Box" with its 
iPhone 5S "Touch ID" technology?   Does this introduce all sorts of 
future pervasive privacy, security, monitoring, tracking, identify 
theft, etc, problems at all levels?  The BI value of this will be 
tremendous, but commercially and for national security.  This 
automation in user identification will be leverage, no doubt, MBA 101. 
Bank it.  Consider, can the government issue a court order to obtain 
the database of the billions of Touch ID fingerprint recordings in the 
name of security, searching for person of interest Apple Network of 
users?  Surely, this issue will be before us one day.

I'm just winging it, perhaps an IETF security-based I-D that suggest 
what kinds of data MUST|SHOULD|MAY NOT collected, stored nor 
transmitted over the internet?  Already done?

Anyway, I don't think every author, developer can muster all system 
level things that can be considered. This is why we do need the 
"Internet/IETF Elders" to be involved in the ethical and moral reviews 
of these super fast tracked documents, and mind you, now increasingly 
proposed as a "Standard" as opposed as just informational, new 
documents to see if the docs themselves are not ultimately April's 
fools jokes.

It probably will not change much, but it will at least make people 
(future developers) think, a few times, about what they are doing. 
Perhaps it will just slow it down.  I'm sure many of us has gone thru 
this in the past where we could of been billionaires if we just were 
not so god darn ethical with user private data. We didn't expose it, 
not because we know it was not possible, but it was just wrong to do so.

Thanks

-- 
HLS

---

From: Stefan Winter <[email-masked]>
Date: Mon, 16 Dec 2013 11:13:44 +0100

Hi,

> Its update, RFC5321, still believes its a small problem but the user is
> no longer arrogant:
> 

The mindset with IETF protocols has always been "be liberal in what you
accept". While a great many of us probably still subscribe to that,
changing that mindset towards: "Be picky in what you accept" is possibly
a better boilerplate to follow, at least in some/many protocols.

As with mail, the liberal acceptance has /technically/ served very well;
emails can be delivered even if they are malformed, don't observe all
protocol functions, opt-out of any kind of step-up functionality (like
auth) etc. The problem is: we don't actually *want* those mails to be
delivered. A "picky" reception of discarding everything that is not
totally well-formed is a much healthier approach - even if it
technically makes for a higher percentage of "failed" communication. It
is the de-facto standard response of mailhubs anyway; pickiness is a
healthy defense, and thus has been deployed to overcome problems in
protocols which face large-scale abuse.

I believe that whenever there is leeway for someone to tamper with a
protocol and get away with it, it will be done so long as there's an
incentive to. Protocol options which are "reserved-zero" but mirrored in
responses can do wonders for fingerprinting and tracking - many more
"attack" vectors are possible. nmap's OS fingerprinting shows what can
be done.

If I were to apply "be liberal in what you accept" to normal
programming, I would soon feel a strong pain in the behind from people
who'd remind me how stupid that is. I guess every developer knows the
mantra that all input that comes in from external needs to be checked
and validated in every possible respect and rejected or mangled if
malformed. This comes from learning over the decades that every lapse in
this regime *will* (not just "could possibly be") exploited if there's
something to gain for an outside attacker.

So, if software devs have learnt that lesson, and have established a
mindset of requiring strict conformance, shouldn't the protocol
designer's mindset follow?

I realise that this makes interop with future revisions of a protocol
much harder - but explicit version negotiation could do its share here.

Is "Be conservative in what you accept, and conservative in what you
send" maybe more appropriate these days?

Greetings,

Stefan Winter

> tremendous, but commercially and for national security.  This automation
> in user identification will be leverage, no doubt, MBA 101. Bank it. 
> Consider, can the government issue a court order to obtain the database
> of the billions of Touch ID fingerprint recordings in the name of
> security, searching for person of interest Apple Network of users? 
> Surely, this issue will be before us one day.
> 
> what kinds of data MUST|SHOULD|MAY NOT collected, stored nor transmitted
> over the internet?  Already done?
> 
> proposed as a "Standard" as opposed as just informational, new documents
> to see if the docs themselves are not ultimately April's fools jokes.
> 
> this in the past where we could of been billionaires if we just were not
> so god darn ethical with user private data. We didn't expose it, not
> because we know it was not possible, but it was just wrong to do so.
> 
> Thanks
> 

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Dec 2013 09:03:45 -0500

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> Absolutely. And I don't think any AD would or should do
    Stephen> that.  As it happens, my experience over the last 3 years
    Stephen> is that the IESG have self-regulated in a way that would
    Stephen> have addressed this anyway. Many or maybe all new ADs (me
    Stephen> included) seem to start out being a bit too enthusiastic
    Stephen> about some aspect of the IETF but after a while, and
    Stephen> sometimes a quiet chat or two, we've all settled down to a
    Stephen> better balance between making progress and being
    Stephen> picky. (Not sure if all authors would agree mind you:-)

HI.
I'm hearing your concern that you believe getting detailed guidance here
would take years and that you think this document is important to
publish sooner than that.
Please read below; I have a specific proposal that I think we can move
on quickly.

I also hear you saying that  the IESG will self-regulate to avoid
gumming up the works.
I agree with that.
However, that self regulation  will be applied very late in the process.
As a result the BCP will have very little impact except on security
considerations text.
And yes, I'd say that this has been a defect of the IESG of the last
three years.

This guidance is something we need WG chairs to understand early in the
process, not ADs to understand late in the process.
As a specific example, I cannot get the guidance from this BCP to know
how to approach  the issues I bring up for any of the working groups
I've ever chaired.
You haven't told me enough to do my job.

Yes, I can try and build consensus within the WG on how the WG feels
about passive attacks.
I don't need this BCP to do that.
What I don't get is a sense of the community's input in how I should
balance the issues surrounding existing protocols and architecture
re-use in my work.  Some aspects of that will be WG specific.  Some
aspects will be places where IETF-wide balance and area-wide balance are
important.
Providing help with that is one of the major values of BCPs like this.

    Stephen> I also don't want to see us wait years before we reduce the
    Stephen> real consensus that exists to words in an RFC. Doing the
    Stephen> most-significant-bit of that now is important IMO.

OK.
I proposed this in my first message but I'll be more clear.

Right now, we decide that the balances I'm looking for are dynamic.
We delegate to the IESG to keep the community informed on the current
balance it sees in the form of an IESG statement.

To move forward I'm looking for:

1) Paragraph describing the existing protocols issue (just what the
issue is, not current thinking) in this document

2) Paragraph describing the architectural re-use issue in this document.

3) Paragraph in this document stating that the IESG will give community
guidance on how they are approaching these issues and update that
guidance as appropraite.

4) Commitment that the IESG is OK with 3.

If we can do that I'm happy accepting that we can handle the issue on an
ongoing basis.

I'm happy to help with 1 and 2 above.
    >> * We're unable to find a way for the IESG and IAB to publish a
    >> document together

    Stephen> That's accurate. Bit, isn't it;-)

I object to a statement claiming that the IESG and IAB cannot publish a
joint architectural statement under our current processes being in a
IETF consensus document.
I believe it to be false.
I appreciate that you failed to think of a way to do so, but I've come
up with several options that I think would work.
I'm not going to get into why I think you're wrong because I agree with
you that it doesn't matter for this document.

I do understand that I'm claiming a number of people who have thought
about how to publish a joint statement and failed to come up with an
answer are wrong.  I'd be happy to discuss details in personal mail if
anyone really cares.  Again, I don't think it matters for this document.
even if we've somehow boxed ourselves in that manner, it's not something
we need to say in this document and saying it makes us look foolish.

I hear your concern that you want to explain why it is different.  I'm
not actually sure we'll all agree on why it is different.  For me it's
different because we have more of a community-focused process now.  I'm
not sure we can do better than saying how we used to do it and that
we're doing what we do now.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 1 Jan 2014 02:27:18 +0100

Hi Sam,

I expect that a BCP document to have solutions of new/old practices.
The document has opinions but no clear reasonable solutions or
guidances for future/past/present protocols. The attacks defined are
mostly on community for long, but when got serious among some this
time then it became an issue,

Comments below

> this document should provide more guidance before publication.

I agree
> The big questions tended to surround protocols already in progress and

I agree, and suggest more clear guides.
> how they mitigate pervasive monitoring.

How can ADs write this BCP without their WGs support (or going through
WG) is it not related to the security area or it is pure general area
or it is related to IESG and IAB. There was a preference in another
thread that a WG chair does not author an adopted work related to that
WG, IMHO, prefer current ADs not to author BCPs related to their Area
only if WGs support it.

>
> Stephen and Sean wouldn't do

I agree that all participants need more time to do better work, why
some want to rush this through LC, will need at least 6 months or
three meetings
> how well you did but don't revisit things.

Yes

>
> If you're in last call, move
> on as usual.

Disagree
> to consider pervasive monitoring in your technology choice.

I see that the document ignores applicability statement section,  and
use cases. I agree with your suggestion of explaining.

>  We've had
> have.

I don't think the community realise the impact, because the document
ignores that also, this document can be used by IESG and ADs.

>
> If we say "use good judgment," and nothing more, then we're
> basically leaving it entirely up to the WGs,

Not only WG, but I think we will leave it also to ADs of those WG areas.

>
>  because cross-area-review
> I think if we provide useful guidance here it can really help.

I support more guide in the doc, and more cross area guide in this doc
which not only security area can produce.

> My

Yes, please provide your input guides, as you mention above that you
can do better.

> Again we've had a lot of heart-ache from not specifying that.

This needs another new document of extensions of existing protocols
and the new doc needs to reference this doc.
> guidance.

Disagree,

>
> I'd support a paragraph describing each issue plus a
> be willing to do that.

I will add another important condition, which is the community or WG
requests such guide related to an issue from IESG or others ( similar
to DT job when they get request from community).

>
> Obviously that would mean we're trusting the

We should not forget that all IESG members are part of community, so
their advise and guide is already received at LC, so why does the
community body (i.e. the WG)leaves its decisions to others.
> I do not support the document remaining silent on these issues.

I agree and support
> community, and a community consensus is how we present really strong

Yes, we all are part of the community but some bodies have different
authorities.
> IAB worked with ISOC to release such a statement and was included in

Yes I agree only that they don't add statements involve in this document.
> publish a joint document.

This document is about attacks on the community not attacks on
leaders. The old internet leaders are responsible for the attacks the
community got these days, so let us leave now the community guide
itself for the future. A WG or DT should do more work on this
document.

>
> The current text really sounds like you

Why not? The attacks (pervasive monitoring) are on all the community
so all WGs may be involved or responsible.

> the list and we could move forward.

Consensus by IETF on supporting a document is different of consensus
on some points, so we need a WG or we need more time to reach the
community (6 months may be the shortest time for this LC).

>
> It's rare that the IETF acts in

I agree we need more details on agreed points and then we need
consensus from WGs on the final document when ready before submission.
IMHO, if this document will be used by IESG then all WGs should agree
on the document.

AB