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.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.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@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
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf