ietf
[Top] [All Lists]

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

2011-03-10 21:48:06
One of the hidden costs of the crypto wars was that we ended up  making
design decisions on the basis of what choice would cause most difficulty for
Louis Freeh rather than what would best meet the needs of end users.

One consequence of this was an absolutist rejection of key escrow in any and
all forms. Which sounded just great to people who have never tried to use or
sell a storage encryption product.

Another mistake was the absolutist insistence on end to end security models
despite abundant evidence that people could not make use of them. Military
communications use end-to-end where possible but they have the luxury of
specialist trained cipher clerks and coms operators.


Both sides lost in the crypto wars. The wrong people got access to strong
cryptography and made use of it. The right people got access to strong
cryptography but with the exception of SSL/TLS it was delivered in a form
that almost nobody would ever use.


If people sincerely want to assist any group of Internet users they have to
first go and talk to those users and find out their actual requirements.
Otherwise they are just using the group as a pretext for their personal
agenda.

Earlier examples of this mode of argument include the argument that the IETF
cannot render technology X historic because it is 'used' in unspecified
remote areas. The assumption being that said remote areas would commence a
1990s modernization program by deploying 1960s mainframe technology.

Another perennial pretext is to claim that technology X is necessary for
some group of disabled persons. Rarely are any members of said group
consulted.

This particular threat seems to be headed in the same direction.


If anyone wants to make a difference here then go talk to the people who are
involved in this work like I have.


On Thu, Mar 10, 2011 at 12:29 PM, 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."

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




-- 
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>