Last call debate on draft-farrell-perpass-attack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I want to weigh in supporting the publication of this document.

I was a document author and then WG chair in CCAMP at a time when it was
exceeding hard to get a GMPLS RFC published because the security considerations
for GMPLS "were not properly documented". I can confess that I became very
disillusioned with the IETF process and with the serving Security ADs at the
time. It took a lot of discussion for me to be convinced that the ADs were doing
what they genuinely thought was best for the Internet (even though they were
wrong ;-)

But it was not the existence of any document describing security consideration
sections that enabled the ADs to block publication. Nor was it some wrinkle in
the process. It was the right and proper process that enables ADs to worry about
the impact on the stability (which includes security) of the Internet when
looking at publication requests. Furthermore, it was not the process per se that
was at fault, it was the enthusiasm of the ADs, and *that* was perfectly
possible to handle using the existing processes (although it was a steep
learning curve for me) and normal discussions about which we should never be
defensive or paranoid.

So, why do I rake up the past now?

This document in its current form does not, IMHO, represent a tool that can be
used by any AD to block or cause delay to the publication of any RFC. If
anything, it provides assistance to authors to enable them to think about some
new yet key issues and include the right discussions in their documents. The
document goes nowhere near as far as RFC 5706 in "dictating" what has to be
documented in a protocol spec yet I don't recall any fuss about that document.
Far from it: this document simply describes the landscape, explains how privacy
attacks may be happening, and indicates that the authors think that such attacks
should be considered in the design of protocols.

And there is a get-out-of-jail-free card that I would find perfectly acceptable:

   This does not mean a new "pervasive monitoring
   considerations" section is needed in IETF documentation.  It means
   that, if asked, there needs to be a good answer to the question "is
   pervasive monitoring relevant to this work and if so how has it been
   addressed?"

Note that that discussion can be in the shepherd write-up, on the mailing list,
in a conversation with the Sec AD during evaluation or (and only if the
authors/WG want to) in the I-D.

I do not find the discussions of opinions voiced against this I-D to be
convincing, and I support its publication.

Thanks,
Adrian







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]