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.
To be honest that seems both overblown and unjustified to me.
I'm also entirely unconvinced by the example below and by your
analysis of how text that says nothing much new is somehow at
the same time horribly threatening. 'Abuse' and setting things
back years and the rest seem to me to bear no relationship to
the text in question.
Stephen,
you might recall interrupting a couple of early presentations we
made on Saratoga to raise a (in hindsight pretty much spurious
and irrelevant) security issue. We could see that you would block
any further work there, and we moved Saratoga away from DTNRG.
DTNRG has since produced a security protocol, rather than
exploring the DTN problem space. It has, in my opinion, set
DTN research back years. DTNRG considered security at
every point.
I view this as an early example of Eliot's doubts.
If you'd had this document then, you'd be pointing at that as well.
The concern is justified. Raise the 'but it's not secure! It's
snoopable!' cry too much, and watch work either die in process,
or leave the IETF.
(Perpass still isn't a working group, is it?)
Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Stephen Farrell
[stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Sent: 19 January 2014 18:54
To: Eliot Lear; 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
On 01/19/2014 08:30 AM, Eliot Lear wrote:
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.
I'm not particularly fussed if this is included or not. I'm ok with
Jari and/or the IESG figuring it out however they do.
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.
To be honest that seems both overblown and unjustified to me.
I'm also entirely unconvinced by the example below and by your
analysis of how text that says nothing much new is somehow at
the same time horribly threatening. 'Abuse' and setting things
back years and the rest seem to me to bear no relationship to
the text in question. Best I can guess is that your fear of
over-zealous ADs causes you to read this text in some way that I
can't figure out, but that argument has been had already for
earlier text which seems to me entirely as strong as this text.
And that's why I included this in -04, it seemed to have support
from others and consideration of architecture is reasonable
and your objection is afaics nothing to do with the text itself
and hence invalid.
But as I said, I'm fine with this being resolved either way.
Cheers,
S.
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