On Thu, Mar 10, 2011 at 9:29 AM, Ed Juskevicius <edj.etc@xxxxxxxxx> wrote: > I also recall a Plenary presentation during IETF 57 in Vienna which > suggested a reversal in the IETF's previous stance on this topic. > http://www.ietf.org/proceedings/57/slides/plenary-10.pdf > > If my memory serves me correctly, I believe the logic was along the lines > of "Law enforcement agencies require some capabilities that are aking to > backdoors. Given this, it would be better if we (who know what we are > doing) designed these capabilities, rather than leave it to others do so." > The result of the discussion, if my memory serves correctly, was to permit those companies or entities interested in IETF review to document their solutions publicly and solicit review, but to clearly state that these were not IETF standards. Fred Baker did so in RFC 3924 "Cisco Architecture for Lawful Intercept in IP Networks". I also think it is worth noting that one of the key conclusions of the Raven discussions, as noted in RFC 2804 and called out in Fred's slides is: Wiretapping ... releases information that the information sender did not expect to be released. –The system is less secure than it could be had this function not been present. –The system is more complex than it could be had this function not been present. –Being more complex, the risk of unintended security flaws in the system is larger. I think, personally, that the "Athens Affair" which Dean mentioned at the start of this thread is a useful, real-world example of how true those conclusions are. The additional complexity of a wiretapping system present in an AXE created security vulnerabilities that simply would not have otherwise been present. regards, Ted Hardie > Regards, > > Ed J. > > On Wed, Mar 9, 2011 at 10:50 AM, Harald Alvestrand <harald@xxxxxxxxxxxxx> > wrote: >> >> Actually, this discussion has been going on for longer than so-far >> referenced docs show. >> >> One of my favourite RFCs on the subject: >> >> RFC 2804 "IETF Policy on Wiretapping." IAB, IESG. May 2000. >> >> The Internet Engineering Task Force (IETF) has been asked to take a >> position on the inclusion into IETF standards-track documents of >> functionality designed to facilitate wiretapping. >> >> This memo explains what the IETF thinks the question means, why its >> answer is "no", and what that answer means. >> >> >> >> On 03/06/11 21:52, Dean Willis wrote: >>> >>> Marc suggested: >>> >>> I any case, may I suggest a Bar BOF in Prague? Plotting >>> revolutions in >>> coffeehouses is a very old tradition. >>> >>> Excellent idea. Perhaps this should be plotted over jasmine tea instead >>> of coffee... >>> >>> >>> The point I really want to stress is that we must stop deliberately >>> designing privacy, integrity, and obscurity weakness into our protocols, >>> and where we can't avoid weakness we should at least consider its >>> implications. We have a real lack of understanding of these issues in the >>> community. For example, if Alice and Bob have a communications session, IETF >>> has never clued onto the fact that Alice and Bob might want intermediary >>> Charlie not jut to be unable to read the data of their session, but to not >>> even be able to know that they have one. We might not be able to hide the >>> fact that Alice has a session with SOMEBODY from her next-door neighbor >>> Allen, or the fact that Bob has a session from his next-door neighbor Burt, >>> but even if Allen and Burt are working together, we should be able to hide >>> the Alice-Bob relationship. >>> >>> What do I mean by not designing weakness into our protocols? I give you >>> SIP, for example. After twelve years of work, I have yet to make a real >>> call using the optional "sips" signaling model. Why? It's optional. Nobody >>> uses it. Actually, I'm having a hard time using even basic SIP any more -- >>> it looks like Google just pulled-the-plug on my telephony ISP service, which >>> had been provided by the Gizmo Project. But that's another problem. >>> >>> -- >>> Dean >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/ietf >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf