I share these concern. Stewart
Sent from my iPad > On 19 Jan 2014, at 08:30, "Eliot Lear" <[email protected]> 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. > > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
