Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscu

+1

Thanks, Henry


On 3/10/11 12:24 PM, "Ted Hardie" <ted(_dot_)ietf(_at_)gmail(_dot_)com> wrote:

> On Thu, Mar 10, 2011 at 9:29 AM, Ed Juskevicius 
> <edj(_dot_)etc(_at_)gmail(_dot_)com> 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(_at_)alvestrand(_dot_)no>
> > 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(_at_)ietf(_dot_)org
> > > > https://www.ietf.org/mailman/listinfo/ietf
> > > _______________________________________________
> > > Ietf mailing list
> > > Ietf(_at_)ietf(_dot_)org
> > > https://www.ietf.org/mailman/listinfo/ietf
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf