Eliot,
On 12/09/2013 07:47 PM, Eliot Lear wrote:
Hi Stephen,
On 12/9/13 5:03 PM, Stephen Farrell wrote:
So, nothing in the draft says "ignore everything else" and it'd
be wrong if it did.
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
there was an implication based on omission.
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?).
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."
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).
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.
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?
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".
I ask because if the effort is Herculean people are just going to route
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",
which is what we the IAB wrote in our statement.
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.
when in fact I found the opposite:
since you laid out explicitly only network management considerations,
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.
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.
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 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.
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.
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.
The
purpose of my change is to remove that implied exclusion, and leave this
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
well, and I don't mind you proposing other wording further to your
liking, so long as we recognize that there are other considerations.
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.
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:-)
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.
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.
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.
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.
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.
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
Eliot