+1 Thanks, Henry On 3/10/11 12:24 PM, "Ted Hardie" <ted.ietf@xxxxxxxxx> wrote: > 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf