+1. if you must publish this, publish as informational, as previous referenced
security docs have been.
A doc that says 'you just haven't considered security enough' is not specifying
the details or scope of a best current practice that can be sensibly followed.
Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Eliot Lear
[lear(_at_)cisco(_dot_)com]
Sent: 19 January 2014 08:30
To: Jari Arkko; Scott Brim
Cc: gen-art; IETF discussion list;
draft-farrell-perpass-attack(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: Gen-Art telechat review of draft-farrell-perpass-attack-04
Jari,
I oppose changes made to the document in the last round as stated below. If
they remain, I would urge publication as Informational and not BCP:
In particular, architectural decisions, including which existing
technology is re-used, may significantly impact the vulnerability of
a protocol to PM. Those developing IETF specifications therefore
need to consider mitigating PM when making these architectural
decisions and be prepared to justify their decisions. Getting
adequate, early review of architectural decisions including whether
appropriate mitigation of PM can be made is important. Revisiting
these architectural decisions late in the process is very costly.
In the fact of a lack of common understanding regarding the threat, this text
can subject a working group to abuse and confusion. This isn't theoretical, as
it has happened in the past that working group chairs and area directors in
particular have derailed efforts, setting standardization and deployment of
useful technology back years, and this wasn't that long ago.
Let's make this discussion concrete with a few examples: the implications may
be that a working group chair or any participant (although chairs are in a very
good position to cause damage) could insist that DHCP not be used to carry new
attributes because there is no common understanding of the scope of remediation
that will be required. Before certain ADs roll their eyes, the discussion gets
derailed as follows:
I propose the following DHCP option to configure my new frob.
<< But DHCP is transmitted in the clear. Please justify this decision.
(or worse) << and by the way here is my very heavy weight alternative that
requires a valid cert chain
It's meant for the local wire.
<< But we don't know the scope of the attack.
...
...
Nevermind, I'll just use a vendor extension. Goodbye.
Rinse and repeat with any other protocol that allows extensions.
It is fair to say that we should consider this threat at an architectural
level. It's fair (albeit a truism) that finding design flaws earlier in the
process rather than later is less costly (ENG-101). Justification language
like the above, however, is likely to actively impede the IETF, as these sorts
of things have in the past.
Eliot