Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Dec 2013 15:53:22 +0100

Hi Stephen,

I'm not comfortable with having this discussion just in perpass, since
the impact of what you are proposing is quite broad, as is my concern. 
This is an IETF last call comment.  The IESG directed those comments to
go to the IETF list.

On 12/9/13 2:23 PM, Stephen Farrell wrote:

>  The chair you mean is Mark
> Nottingham in this [1] mail to the httpbis list.
>
>    [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1453.html
>
> I definitely did not read him the way you appear to have and
> that distinction matters. If you are the only one to take him
> as saying that then I guess you'd agree that your changes
> would be based on a fallacy. Maybe Mark can clarify but I think
> its already crystal clear that he was not saying "ignore
> everything else" - I'd be stunned if that was what he meant.

The point was and is that I wanted to respond to him to clarify that one
should not ignore everything else, when in fact I found the opposite:
since you laid out explicitly only network management considerations,
the implication is that all other considerations are excluded.  The
purpose of my change is to remove that implied exclusion, and leave this
to working groups to wrestle with.  I'm happy with Robin's wording as
well, and I don't mind you proposing other wording further to your
liking, so long as we recognize that there are other considerations.

If you can show me where in your text it allows for those other
considerations as I believe I've done in the reverse, I'll be happy to
stand corrected.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Dec 2013 15:57:31 +0100

> This is an IETF last call comment.  The IESG directed those comments to

Just on this point, Stephen pointed out that I had originally CC'd the
wrong list.  Apologies to Stephen and others for any confusion about that.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Dec 2013 16:03:15 +0000

Hi Eliot,

> This is an IETF last call comment.  The IESG directed those comments to

WFM. I agree sticking to [email-masked] for this is right.

> should not ignore everything else, 

So, nothing in the draft says "ignore everything else" and it'd
be wrong if it did. Pervasive monitoring is an attack and like
the draft says:

   The IETF also has consensus to, where possible, work to mitigate the
   technical parts of the pervasive monitoring attack, in just the same
   way as we continually do for these and any other protocol
   vulnerability.

I think that's quite clear - we handle it the same as for "any
other protocol vulnerability."

> when in fact I found the opposite:

But the above already says that this is just another threat.
An important one? Sure. Overrides everything else? Of course not.

But yes we called out one significant area where there's an obvious
tension caused by mitigating this threat but where there's also
an obvious need for some forms of monitoring in order to ensure
that networks can be managed.

> the implication is that all other considerations are excluded.  

I don't read the draft that way at all fwiw. If everyone did,
that'd be something to fix though, I agree.

> The
> to working groups to wrestle with.  

Working groups will have to wrestle with this BCP yes. In some
cases that'll be easy. In other cases, hard.

> I'm happy with Robin's wording as

As I read it, that's there already in the text quoted above.
I don't think we want to try to list every possible other
consideration, or we'll never get this done.

> considerations as I believe I've done in the reverse, I'll be happy to

My reluctance to extend a get-out-of-jail card here should be
fairly obvious, but I think its important that we recognise that
there will be people who from time to time will want to work around
the IETF consensus on this topic.

If your argument was "why just call out network management" that's
a good question, but to be honest the alternative wordings I've seen
so far do seem to offer a broad get-out-of-jail card and I don't
believe that represents the overwhelming consensus we had in the
room in Vancouver, which what this draft attempts to document.

Cheers,
S.

> 
> Eliot
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Dec 2013 20:47:03 +0100

Hi Stephen,

On 12/9/13 5:03 PM, Stephen Farrell wrote:
> be wrong if it did. 

Please let's not have straw men tossed around.  What I wrote was that
there was an implication based on omission.

> Pervasive monitoring is an attack and like
> the draft says:
>

Well except you go on to write:

> This BCP simply records the consensus to design protocols so as to
> mitigate the attack, where possible.
Nothing about practicality or engineering tradeoffs that need to be
addressed (except network management).  And the logic is circuitous at best.

If we were to apply these same rules to development of a protocol that
allows for intercepting/transparent proxies for purposes of data
caching, how far would you go to mitigate?

I ask because if the effort is Herculean people are just going to route
around us.  A simple fix would be to change "possible" to "practical",
which is what we the IAB wrote in our statement.

> that networks can be managed.

So back to our example: would transparent/intercepting proxies be
something you bounced back if the working group decided to allow them
after due consideration?  I ask because that is still a possible outcome.

> that'd be something to fix though, I agree.

But it doesn't have to be everyone to be a problem, and what's more,
when one person appeared to have read it that way, I had no backing in
the document to correct it.

> consideration, or we'll never get this done.

I didn't ask for that, nor does his wording suggest that.

> the IETF consensus on this topic.

What you call a "get-out-of-jail" card may be simple operational reality
which is why  I keep bringing us back to the case of a
bandwidth-constrained network that does transparent/interception
caching.  I don't see how the new rules would permit the mechanisms that
save service providers and their customers huge amounts of bandwidth and
delay.

Also, not for nothing, but the poll at the IAB meeting was the beginning
of a process and not its end.  Nobody had an opportunity to explore the
ramifications of their decisions, which is what engineers need to do.

Eliot

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Dec 2013 21:10:40 +0000

> after due consideration?  I ask because that is still a possible outcome.
In order to avoid any possibility of intercept in many systems, you need to
use full end-to-end encryption, where the ends are "here" and "eternity"
respectively.

I'm not sure there's any way of preventing a transparent proxy when the end
users desire it, for that matter, but they might well end up having to
entirely break their own security in doing so.

As such, I would expect (and hope) that rather than forcing cases to use
nasty things like "magic CA" TLS MITM proxies where the provider has to, by
necessity, MITM *all* data, we'd acknowledge that there exist some
use-cases where no mitigation is possible, and any heavy-handed approaches
to mitigation may prove worse in those cases than no mitigation at all.

I've currently got visions of a private key painstakingly written out onto
a post-it note on the side of the monitor.

Dave.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Dec 2013 21:56:35 +0000

Eliot,

On 12/09/2013 07:47 PM, Eliot Lear wrote:
> Please let's not have straw men tossed around.  

I don't think that's a strawman - wasn't that exactly what you
claimed Mark had meant in his mail?

> What I wrote was that

This ~2 page draft omits entire encyclopedias worth of content.
And I really don't see the implication that you claim is there
(and that you now appear to call a strawman?).

> addressed (except network management).  

Yes. This draft aims only to document the consensus, not the detail
that will be needed in various WGs and elsewhere. This is not the
place to document specific engineering trade-offs for various reasons
that I outlined in response to Wes on this list already and that he
seems to have found reasonable.

> And the logic is circuitous at best.

How exactly? Can you be specific? That's not really useful.

> caching, how far would you go to mitigate?

As I said before the httpbis WG are working through the complex
and involved issues related to HTTP and TLS and proxies. Do you
expect this to short-circuit that WG's efforts? And why would my
particular opinion of that be interesting here? Seriously I've no
idea what answer you expect there as to "how far" *I* "would go
to mitigate".

> around us.  

I suspect you mean HTTP here again. If so, my answer is the
same which is to discuss that on the httpbis WG list.

> A simple fix would be to change "possible" to "practical",

Hmmm. I saw the IAB exhorting people to "...also take practical
measures..." is that what you meant? If so, that seems quite
different to what you imply above which would be to
s/where possible/where practical/

By itself s/where possible/where practical/ might be ok, but given
that your interpretation of "where practical" appears to call for
allowing TLS MITM attack boxes, if that's what you mean by intercepting
proxy, I'd be very leery of accepting such a suggestion. In fact,
the new BCP isn't (IMO) needed to reject such things, the security
area has consistently chosen to reject those, for various good reasons
none of which require this draft. If you don't mean TLS MITM attack
boxes, then being more specific would be good but you are then
definitely asking to preempt the work of the httpbis WG which has
only recently gotten over this TLS MITM attack box approach and
started real discussion related to standardising proxy behaviour
when TLS is involved.

That's also why your (or Robin's) suggested text seems wrong to me
at least - it could cause significant confusion say when compared to
RFC 2804 and that would be a terrible outcome. That was for example
Eric Burger's immediate and quite correct reaction to your suggested
text.

> after due consideration?  I ask because that is still a possible outcome.

I and others have expressed various opinions on HTTP proxies on
the httpbis WG list. I don't plan on reiterating them here.

For someone who claims to be worried that this BCP will undermine
WG freedoms, you seem keen to preempt a current and difficult
WG discussion in this BCP. Doesn't that strike you as a contradiction?
It does strike me that way.

> the document to correct it.

I don't know what you mean. I don't know of anyone else who appears
to be mis-reading the draft as you are. If that mis-reading were
common, then yes it would need fixing. If (as I suspect) its not
common, and your concern is really related to a httpbis specific
topic, then you ought take that concern to the WG.

That's not to say the text is perfect. But I honestly don't believe
that the implication you're claiming is there, and I do think that's
entirely clear.

> I didn't ask for that, nor does his wording suggest that.

Good. (That we're not going to get death by 1000 cuts attempted here:-)

> save service providers and their customers huge amounts of bandwidth and

I'll repeat myself again. HTTP and proxies are being discussed in
the httpbis WG. If, as appears to be the case, that issue is what
you find most pressing, then you really should dive into that on
the httpbis list. Again, let's not try preempt the httpbis WG
discussion via text inserted into this draft that's neither needed
nor useful and that could effectively neuter this BCP.

> ramifications of their decisions, which is what engineers need to do.

The hum was overwhelming and for the content of this draft. There's
some video of some IAB members on the stage applauding that hum on
youtube. [1], at 2:29:28 for example catches a happy looking Eliot
doing exactly that;-)

Stephen.

[1] https://www.youtube.com/watch?v=oV71hhEpQ20

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Dec 2013 06:56:22 +0100

Jumping down a bit, to what I think is the point...

On 12/9/13 10:56 PM, Stephen Farrell wrote:
> allowing TLS MITM attack boxes

Where did THAT come from?  I never made any such statement or even
alluded to such an idea.  We have developed an entire ecosystem that was
predicated on encryption NOT being in certain places.  If we can do
better while not destroying people's ability to operationally manage

> idea what answer you expect there as to "how far" *I* "would go

Quite the opposite, I am concerned that we do not understand the
implications of what happens to a document when it comes out of a
working group and hits the IESG.  Will operational realities still
apply?  That's why I want to know your thinking in an EXAMPLE I gave
(not for doing the HTTP WG's work - they should be left to do it).  And
you seem to be unwilling to answer that question.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 12:10:52 +0000

Hiya,

On 12/10/2013 05:56 AM, Eliot Lear wrote:
> alluded to such an idea.  

But isn't TEMPORA an "operational reality"? And CALEA?
And aren't TLS MITM attack boxes?

Perhaps that last is not what you had in mind when you use
the term operational reality. And I'd hope that you don't
mean the first. And we had the discussion about the middle
one and got to 2804. But the text you suggested would
appear to call for not considering any of the above as being
part of the pervasive monitoring attack since they are part
of the "operational reality." To me, that's nonsensical.

But even if better phrased, including such ambiguity in
this draft, and especially when that would also create a
conflict with 2804 seems like a really bad idea.

> We have developed an entire ecosystem that was
> their network, great.  But I never went into mechanism.  

Fair enough. The draft already says that unmanageable networks
wouldn't be an acceptable outcome though, so again I don't
see what change is needed.

> What's more:
> working group and hits the IESG.  

I don't know how to answer in a usefully different way, the
draft says that we treat pervasive monitoring in the same way
we treat any other threat. The IESG then apply the discuss
criteria as usual as part of IESG evaluation, but you can't
be asking that that kind of text be added are you?

I'm just not seeing what else needs to be stated in this draft.

> Will operational realities still
> apply?  

See above for why that phrase doesn't help. If the draft is to
call out anything then that has to be done extremely carefully
so as not to effectively neuter the entire thing.

> That's why I want to know your thinking in an EXAMPLE I gave

Yes, I'm not willing to go there because I'm part of that
discussion as an IETF participant but will also be involved
in the IESG evaluation of the outcome (*) and that's already
a tightrope to walk - asking me to say now how I'll judge
the httpbis outcome that doesn't yet exist against this BCP
which isn't yet final, isn't fair, nor useful, nor, I maintain,
even relevant and that last for the reasons I've explained
a number of times ("just another threat").

And on that, I'd ask that you step back from your concerns
with HTTP and consider how this BCP would be read in say
10 years time. Crafting it specially now so as to lead to
(or avoid) some specific outcomes related to the current
httpbis work seems very short-sighted to me, and that is
how I perceive what you're asking for.

Stephen.

(*) Assuming no recalls etc.:-)

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Dec 2013 15:45:52 +0200

First, I have a personal opinion. I did not get the same impression from the draft as you did Eliot that other considerations are excluded. But I do think that "where possible" is broader than mere theoretical feasibility. An example: One of the debates in a WG that wanted to do more for security of their application was about which one of two possible technical solutions would result in a bigger practical impact. When we actually go and do something about our protocols we have to make decisions like that, and they all are ultimately weighed decisions of how important we think various aspects are, or predictions about future things. Normal course of work in our WGs.

I do get however Stephen's reluctance to make a too soft statement. Because I think we do as a community want to improve on the technical protection against pervasive surveillance. And I think it would be a bad idea to water the statement down too much - I compare the situation to the time that we wrote the strong crypto BCP, and at that time it might be been arguably "practical" to just use weak crypto given all export regulations and other hassles. But we prevailed, and we need to push boundaries again today.

FWIW, I was never particularly fond of the text that talked about network management and monitoring. I could probably personally live with a broader statement only that said something like "where technically feasible and can provide improved security in practical deployments". YMMV.

Second, as the sponsoring AD I wanted to remind everyone that we're trying to determine the IETF's opinion on this matter. This may involve text changes. At the plenary Brian reminded us that it took a long time to get the previous BCPs done (even if I think the IETF started acting accordingly pretty soon). We do want to get this right, and the BCP needs to make as much sense in the future as some of the older BCPs make sense today. Also, since this is about the IETF's opinion, neither mine, the authors, or individual commenter's opinion may be exactly reflected in the end result. 

Jari

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 10 Dec 2013 08:53:16 -0500

On Tue, Dec 10, 2013 at 12:10:52PM +0000, Stephen Farrell wrote:
> ...

I don't think we can make any changes here already, but I'll note the
ambiguity is enough that in this brand-new multi-stakeholder world,
what if the Chinese government shows up and claims that without TLS
MITM attack boxes, in their opinion the network is "unmanageable"?

(Of course they will mean in the political sense, but who's to make
the call about whether a network is really unmanageable from a
political or an operational standpoint?)

And the NSA has already tried making the case that passing unencrypted
packets as well as "just metadata" to their collection boxes it the
only way to protect the nation against malware.  If we accept that
this is also required for a "manageable network", then we can't do
anything at all, which I hope is not what we consider a desired
outcome....

So if anything, the draft may be too ambiguous and mealy-mouthed
already, although from a political standpoint it may not be possible
to remove that phrase.

					- Ted

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 10 Dec 2013 10:06:23 -0800

On 12/10/13 5:45 AM, "Jari Arkko" <[email-masked]> wrote:

>FWIW, I was never particularly fond of the text that talked about network
>management and monitoring. I could probably personally live with a
>broader statement only that said something like "where technically
>feasible and can provide improved security in practical deployments".
>YMMV.

Perhaps "management" is a misnomer for the fundamental concern, which is
the ability to operate the network. The text that discusses management
could be made more accurate by instead discussing operation, e.g.:

OLD:
More limited-scope monitoring to assist with network management that
   is required in order to operate the network or an application is not
considered pervasive monitoring.

NEW:
More limited-scope monitoring that
   is required in order to operate the network or an application is not
   considered pervasive monitoring.

OLD:
Making networks unmanageable in order to mitigate
   pervasive monitoring would not be an acceptable outcome.

NEW:
Making networks inoperable in order to mitigate
   pervasive monitoring would not be an acceptable outcome.

(Realizing that now is not the time to wordsmith, but just offering
examples that might address the concerns raised earlier in the thread by
Eliot and others.)

Alissa

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 11 Dec 2013 10:50:20 +0000

FWIW - I would be fine with wording changes on the lines of what Alissa is suggesting. Mentioning network operations rather than network management is more accurate actually in this case. What we usually call 'network management' is part of the toolset needed to operate networks.

Regards,

Dan

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Sent: Tuesday, December 10, 2013 8:06 PM
> To: Jari Arkko; Stephen Farrell; Eliot Lear
> Cc: [email-masked]
> Subject: Re: [perpass] comments and questions for the group on draft-
> farrell-perpass-attack-02
> 
> >FWIW, I was never particularly fond of the text that talked about
> >network management and monitoring. I could probably personally live
> >with a broader statement only that said something like "where
> >technically feasible and can provide improved security in practical
> deployments".
> >YMMV.
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Dec 2013 13:07:22 +0000

Hi Alissa,

On 12/10/2013 06:06 PM, Alissa Cooper wrote:
> Perhaps "management" is a misnomer for the fundamental concern, 

Yeah, I think management isn't quite right but I've yet to
see anything else that doesn't create holes big enough to
drive a PRISM through;-)

> which is

Can you give examples of what is "not required" to operate
the network? Couldn't CALEA be so considered? And if so,
wouldn't that make this BCP conflict badly with 2804?

S

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Dec 2013 08:56:06 -0500

> wouldn't that make this BCP conflict badly with 2804?

CALEA is not a network management requirement, it is a compliance
requirement. I can manage a network perfectly well without supporting CALEA.

Preventing spam, DDoS attacks, Botnets etc. are network management
requirements that require some form of performance monitoring at the very
least.

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 10:14:28 -0500

Operations is just one aspect of what is already covered in 2119
SHOULD/MUST distinctions. A WG can have lots of reasons why it
recommends but does not insist on a particular capability, including
operations considerations. It's okay with me if operations is
mentioned in the draft as an _example_ but it should be cited as such.
The text above makes it look like operations is the only, or at least
overwhelming, issue.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2013 08:15:28 +1300

On 12/12/2013 02:07, Stephen Farrell wrote:
...
> the network? 

Well, is the degree of deep packet inspection performed by a
load balancer or a diffserv classifier "monitoring"? What about
a web cache that looks at your URL to discover whether or not
it has a cached copy? These are things widely considered to be
vital parts of normal operation, but they may be looking at every
packet you send. However, they could all be readily suborned for
surveillance purposes.

Is Netflow or IPFIX "monitoring"? They're also considered vital
by some operators. They are also prime sources for traffic
analysis.

On the other hand a classical router that *only* looks at the
destination address and logs nothing is presumably not "monitoring"
in anybody's book.

I think Alissa's phrasing is just fine.

    Brian

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 11 Dec 2013 12:08:18 -0800

>wouldn't that make this BCP conflict badly with 2804?

By "operate" I was literally thinking about the technical functioning of
the network -- whether the network can be made to work. For example, if a
network operator feels that in order to follow this BCP it must stop all
DDoS mitigation, and as a result the network is constantly flooded with
attack traffic that renders the network essentially unusable for
legitimate users, the network would have been made inoperable. It wouldn't
be able to do what it was meant to do, which is provide connectivity. I
realize that this is using the word "operate" more like the dictionary
definition and less like we usually use the term "operations" in the IETF
(per Scott's email), but I think it works.

I don't see any reasonable argument that a network would have to support
CALEA compliance in order for it to be functional/operational -- surely
networks can be built (and already exist, in people's homes, outside the
US, etc.) that both provide connectivity and are not CALEA-compliant.

Alissa