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 >