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