Stewart, On 12/12/2013 10:42 AM, Stewart Bryant wrote: > On 11/12/2013 15:07, Scott Brim wrote: >> Regarding "where possible", since every situation is different, I do >> not think the IETF should try to find a balance, or say anything >> universal about deployment. There is no position that will work for >> everyone. The IETF should absolutely try to make privacy/security a >> _possibility_, and that's why every effort should offer the >> _possibility_ of mitigation. That's as far as we should go. >> . >> > I would like to explore this a bit more if I may. > > RFC3552 says we must describe > > 1. which attacks are out of scope (and why!) > 2. which attacks are in-scope > 2.1 and the protocol is susceptible to > 2.2 and the protocol protects against I'll note that many of the 2119 MUSTs in 3552 aren't enforced in practice - generally secdir reviews and the like are much more reasonable and try to figure out whether or not a draft has done a good enough job and those reviews do not include mindless checking of boxes as to whether the MUSTs from 3552 have been met. I'm sure the same is true for other area reviews as well - we're all basically a fairly practical bunch who want work to get done and done well, but we don't want to build a form-filling bureaucracy. (Well, the IETF does have a tendency to wander in that direction but then some of us also push back the other way as well:-) Separately, I would argue that this draft takes a better approach than the overly prescriptive parts of 3552. I think the informative parts of 3552 are much more useful than the 2119 language parts. So if you're worried that this BCP will suddenly mean that the security area starts to jump down everyone's throat, then I'd say you should relax. The security area already has plenty of BCP ammunition in that respect, but luckily doesn't behave like a set of process-obsessed fools. And it won't start doing that either is my pretty confident prediction. This BCP will have no effect on that at all. > Now consider the attack that caused us to start this work programme > and think about RFC791. Would that pass security review against > the new hurdles? > > I think that the answer to 2.1 is: This protocol is susceptible to a > metadata harvesting attack of the protocol, and moreover it > provides an essential clue in analyzing the payload. It also > provides essential clues in determining the topology of the > network to an observer and thus making other network > elements vulnerable to attack. > > So would RFC791 be accepted for publication with its vulnerability > to a pervasive monitoring attack? Answers to counterfactual questions won't get us very far, so please take this with the large pinch of salt it deserves. The text of RFC791 would almost certainly be bounced today for loads of reasons. Things have moved along a lot in the 32 years since that was published. So my answer is "no" - it'd not be accepted for publication for lots of reasons. I don't think its useful to speculate as to which issue would be the most blocking in the alternative universe you're envisaging where we re-invent IP in 2013. (And I hope people who want to explore that alternative universe start new threads for that:-) But I don't see what you're hoping to learn from any answer to that counterfactual question to be honest. Cheers, S. > > - Stewart > > >