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

From: Dean Willis <[email-masked]>
Date: Fri, 4 Mar 2011 22:06:16 -0600

I just came across what may be old news to many of you. The July 2007 issue of IEEE Spectrum included an article entitled "The Athens Affair", subtitled "How Some Extremely Smart Hackers Pulled Off The Most Audacious Cell-Network Break-in Ever". In short, perpetrators appear to have accessed the lawful-intercept component of mobile switches in-use, and were able to tap a lot of phones, including that of the Prime Minister of the host nation.  Apparently this was made easier by the fact that the user-interface for the LI component had not yet been installed, making it possible for the interceptions to go undetected for some time.

This is just an example of a maxim: if we build nefarious mechanisms into systems, SOMEBODY is going to abuse them. Otherwise said: If you build in a back-door, don't be surprised when somebody sticks something in it. Sure, any meathead can slap a microphone on a window, order the withdrawal of a bunch of BGP routes, or cut the power to a switching center. There's not a lot we can do about that. But we can do a lot about a wide variety of "man in the middle" attacks, if we're willing to step up and confront the bullies out there, along with the misguided who don't understand why security back-doors are a two-edged sword, as dangerous to themselves as to their opposition. Sure, everybody wants their systems to be "secure" and their opposition's systems less so, but in the real world, everybody is somebody's opposition. The only way to be safe is to have universal protections. Start by locking yourself out. If that works, then it MAY stop the bad guys too.

So what can we do about it?

Every document we now produce has a "Security Considerations". I hereby propose the following extensions to that  section, such that each specification requiring a meaningful Security Considerations section MUST address the following:

1)  Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users. How are the principles of end-to-end privacy and integrity provided by the specification? Reasonable solutions might include any of our well-documented encryption and signature systems coupled with applicable key management mechanisms. Analysis within the specification should also describe the known limitations of the specification, such as susceptibility to hostile certificate authorities. Further, forthcoming IETF specifications MUST not allow plain-text transmission of anything within any protocol. Sign or cipher (or both, as appropriate) everything, all the time.

2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible to an intermediary who observes the traffic without the explicit consent and awareness of the user.  In principle, "deep packet inspection" should be completely useless, as should attempts by an intermediary to trace the end-user(s) to a specific physical location. How does the specification provide for obscuring the content of the application and the identity and location of users involved in the sequence?  Reasonable solutions might include things like TOR combined with TLS. Analysis within the specification should also describe known limitations of the specification, such as frequency and time domain analysis at a network-adjacent node, or dependency on interceptible dereferencing mechanisms like the DNS. 

Currently we have millions of people using our protocols to defend themselves from aggressors, who typically have more reach "into the infrastructure" than the end users do. I know the utilization on my TOR exit relay has been 100% for several months now, so there are clearly people who understand enough of the problem to be attempting  some sort of defense. And we have persons in authority who find open communication threatening and frequently "shutting down" access to parts of the net, such as LinkedIn, Facebook, Skype, Blackberry Messenger, or whatever they deem threatening on any given day. We can't keep them from turning off the whole Internet, but if we design protocols correctly, we can force them to choose between participating in the civilization of the Internet, ALL OF IT, or being completely isolated. 

If we do NOT act on this proposal, then our misguided leaders, censors, tyrants, and fools will continue to be able to piecemeal select which parts of the Internet they will allow, thereby manufacturing their own self-serving subsets of "the truth". At the same time, criminals will continue to exploit  protocol weaknesses to spam, spoof, steal, and subvert. And the Internet will not be the mechanism for peaceful economic expansion, prosperity, and interpersonal communication that it could be.

Much, I think, can be judged about respondents to this manifesto by the nature of their response. Many will quite reasonably say "This is hard to do". I agree; we can't expect immediate perfect answers, just as we know we've never been able to get perfect answers to most any security question, we know we will never produce perfect solutions for these issues. Others will say that these goals are undesirable. I suspect that these individuals are either proprietors of deep-packet-inspection tools, thieves, or accessories to the overbearing governments who employ and enable the afore-mentioned classes of miscreant. Others may agree wholeheartedly, but flinch at the political repercussions. To them, I say: Step up. No good deed goes unpunished, but at least the goal is worthwhile.  And it's probably safer than standing in front of a tank or a camel-cavalry charge, although less likely to get you remembered. Yet others may ask why this proposal is made now, rather than the first of next month. To them, I say that timing is everything.

--
Dean Willis

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 5 Mar 2011 13:30:40 +0200

Hi Dean, 

you may want to look at the following two documents:

1) "The Role of the Internet Engineering Task Force (IETF) in Improving Privacy on the Internet"
http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-32.pdf
by Jon Peterson, Neustar; Hannes Tschofenig, Nokia Siemens Networks; Bernard Aboba, Microsoft and Karen Sollins, MIT

2) "Privacy Considerations for Internet Protocols: Bringing Privacy to the IETF"
http://www.tschofenig.priv.at/svn/dagstuhl-privacy/ietf-privacy-overview.pdf
by Hannes Tschofenig, Bernard Aboba, Jon Peterson

These two documents contain several references, including pointers to 

* the recent IAB/W3C/ISOC/MIT workshop on Internet privacy:
http://www.iab.org/about/workshops/privacy/

* Privacy Considerations for Internet Protocols
http://tools.ietf.org/html/draft-morris-privacy-considerations-02

* Policy Considerations for Internet Protocols
http://tools.ietf.org/html/draft-morris-policy-cons-00

* Terminology for Talking about Privacy by Data Minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management
http://tools.ietf.org/html/draft-hansen-privacy-terminology-01

When you read through these documents then you will find out that 
* "privacy" is a fairly complex topic, 
* privacy has been addressed in IETF protocols in various degrees, and 
* there is work ongoing to consider privacy in a more systematic way in the IETF. 

Ciao
Hannes

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 06 Mar 2011 07:52:45 -0800

On 03/04/2011 08:06 PM, Dean Willis wrote:
> Much, I think, can be judged about respondents to this manifesto by the nature of their response. Many will quite reasonably say "This is hard to do". I agree; we can't expect immediate perfect answers, just as we know we've never been able to get perfect answers to most any security question, we know we will never produce perfect solutions for these issues. Others will say that these goals are undesirable. I suspect that these individuals are either proprietors of deep-packet-inspection tools, thieves, or accessories to the overbearing governments who employ and enable the afore-mentioned classes of miscreant. Others may agree wholeheartedly, but flinch at the political repercussions. To them, I say: Step up. No good deed goes unpunished, but at least the goal is worthwhile.  And it's probably safer than standing in front of a tank or a camel-cavalry charge, although less likely to get you remembered. Yet others may ask why this proposal is made now, rather than the first 
of
>   next month. To them, I say that timing is everything.

There is two other interesting efforts in this direction.  The first one is
Douglas Rushkoff call to fork the Internet:

http://www.shareable.net/blog/the-next-net

Another, more concrete, one is Eben Moglen's Freedom Box Foundation:

http://www.freedomboxfoundation.org/

I any case, may I suggest a Bar BOF in Prague?  Plotting revolutions in
coffeehouses is a very old tradition.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Marc Manthey <[email-masked]>
Date: Sun, 6 Mar 2011 17:33:12 +0100

Am 06.03.2011 um 16:52 schrieb Marc Petit-Huguenin:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I just came across what may be old news to many of you. The July  
>> 2007 issue of IEEE Spectrum included an article entitled "The  
>> Athens Affair", subtitled "How Some Extremely Smart Hackers Pulled  
>> Off The Most Audacious Cell-Network Break-in Ever". In short,  
>> perpetrators appear to have accessed the lawful-intercept component  
>> of mobile switches in-use, and were able to tap a lot of phones,  
>> including that of the Prime Minister of the host nation.   
>> Apparently this was made easier by the fact that the user-interface  
>> for the LI component had not yet been installed, making it possible  
>> for the interceptions to go undetected for some time.
>>
>> This is just an example of a maxim: if we build nefarious  
>> mechanisms into systems, SOMEBODY is going to abuse them. Otherwise  
>> said: If you build in a back-door, don't be surprised when somebody  
>> sticks something in it. Sure, any meathead can slap a microphone on  
>> a window, order the withdrawal of a bunch of BGP routes, or cut the  
>> power to a switching center. There's not a lot we can do about  
>> that. But we can do a lot about a wide variety of "man in the  
>> middle" attacks, if we're willing to step up and confront the  
>> bullies out there, along with the misguided who don't understand  
>> why security back-doors are a two-edged sword, as dangerous to  
>> themselves as to their opposition. Sure, everybody wants their  
>> systems to be "secure" and their opposition's systems less so, but  
>> in the real world, everybody is somebody's opposition. The only way  
>> to be safe is to have universal protections. Start by locking  
>> yourself out. If that works, then it MAY stop the bad guys too.
>>
>> Every document we now produce has a "Security Considerations". I  
>> hereby propose the following extensions to that  section, such that  
>> each specification requiring a meaningful Security Considerations  
>> section MUST address the following:
>>
>> 1)  Privacy and Integrity: We believe that intermediaries should be  
>> neither able to understand nor alter the transmitted material  
>> without the explicit consent and awareness of the users. How are  
>> the principles of end-to-end privacy and integrity provided by the  
>> specification? Reasonable solutions might include any of our well- 
>> documented encryption and signature systems coupled with applicable  
>> key management mechanisms. Analysis within the specification should  
>> also describe the known limitations of the specification, such as  
>> susceptibility to hostile certificate authorities. Further,  
>> forthcoming IETF specifications MUST not allow plain-text  
>> transmission of anything within any protocol. Sign or cipher (or  
>> both, as appropriate) everything, all the time.
>>
>> 2) Privacy and Obscurity: We believe that observation of a traffic  
>> flow pr sequence of traffic flows should reveal as little  
>> information about the application or user of the application as  
>> possible to an intermediary who observes the traffic without the  
>> explicit consent and awareness of the user.  In principle, "deep  
>> packet inspection" should be completely useless, as should attempts  
>> by an intermediary to trace the end-user(s) to a specific physical  
>> location. How does the specification provide for obscuring the  
>> content of the application and the identity and location of users  
>> involved in the sequence?  Reasonable solutions might include  
>> things like TOR combined with TLS. Analysis within the  
>> specification should also describe known limitations of the  
>> specification, such as frequency and time domain analysis at a  
>> network-adjacent node, or dependency on interceptible dereferencing  
>> mechanisms like the DNS.
>>
>>
>> Currently we have millions of people using our protocols to defend  
>> themselves from aggressors, who typically have more reach "into the  
>> infrastructure" than the end users do. I know the utilization on my  
>> TOR exit relay has been 100% for several months now, so there are  
>> clearly people who understand enough of the problem to be  
>> attempting  some sort of defense. And we have persons in authority  
>> who find open communication threatening and frequently "shutting  
>> down" access to parts of the net, such as LinkedIn, Facebook,  
>> Skype, Blackberry Messenger, or whatever they deem threatening on  
>> any given day. We can't keep them from turning off the whole  
>> Internet, but if we design protocols correctly, we can force them  
>> to choose between participating in the civilization of the  
>> Internet, ALL OF IT, or being completely isolated.
>>
>> If we do NOT act on this proposal, then our misguided leaders,  
>> censors, tyrants, and fools will continue to be able to piecemeal  
>> select which parts of the Internet they will allow, thereby  
>> manufacturing their own self-serving subsets of "the truth". At the  
>> same time, criminals will continue to exploit  protocol weaknesses  
>> to spam, spoof, steal, and subvert. And the Internet will not be  
>> the mechanism for peaceful economic expansion, prosperity, and  
>> interpersonal communication that it could be.
>>
>>
>> Much, I think, can be judged about respondents to this manifesto by  
>> the nature of their response. Many will quite reasonably say "This  
>> is hard to do". I agree; we can't expect immediate perfect answers,  
>> just as we know we've never been able to get perfect answers to  
>> most any security question, we know we will never produce perfect  
>> solutions for these issues. Others will say that these goals are  
>> undesirable. I suspect that these individuals are either  
>> proprietors of deep-packet-inspection tools, thieves, or  
>> accessories to the overbearing governments who employ and enable  
>> the afore-mentioned classes of miscreant. Others may agree  
>> wholeheartedly, but flinch at the political repercussions. To them,  
>> I say: Step up. No good deed goes unpunished, but at least the goal  
>> is worthwhile.  And it's probably safer than standing in front of a  
>> tank or a camel-cavalry charge, although less likely to get you  
>> remembered. Yet others may ask why this proposal is made now,  
>> rather than the first
> of

exellent suggestions marc, i just downloaded  " offload "
I would suggest any interested person to join
http://lists.zooko.com/pipermail/p2p-hackers/2011-February/thread.html
and  http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
because there was a very interested  discussion about this topic lately

regards

and nice

weekend

Marc

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk1zrcwACgkQ9RoMZyVa61fpVwCfdWEon6KCA7y9rqIhnWoQ4GhB
> YpEAoKkHHcTH3GKduSOKl3W2hK7FJdRF
> =o/mR
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

--  
Les enfants teribbles - research / deployment
Marc Manthey- Vogelsangerstrasse 97
50823 Köln - Germany
Tel.:0049-221-29891489
Mobil:0049-1577-3329231
blog: http://let.de
project : http://opencu.org
twitter: http://twitter.com/macbroadcast/
facebook : http://opencu.tk

Opinions expressed may not even be mine by the time you read them, and  
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Scott W Brim <[email-masked]>
Date: Sun, 6 Mar 2011 12:01:08 -0500

> coffeehouses is a very old tradition.

I am told that http://www.cafeslavia.cz/ was a popular hangout for Czech
revolutionaries.

---

From: Dean Willis <[email-masked]>
Date: Sun, 6 Mar 2011 14:52:45 -0600

> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 06 Mar 2011 14:43:39 -0800

On 03/06/2011 12:52 PM, Dean Willis wrote:
> Excellent idea. Perhaps this should be plotted over jasmine tea instead
> of coffee... 
> 
> 
> 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.

My very cynical view of this is that if encryption is one day available for
every computer and devices, this will be so the cloud services can hide their
activity siphoning all the privacy information from these devices.

- -- 
Marc Petit-Huguenin

---

From: SM <[email-masked]>
Date: Sun, 06 Mar 2011 17:52:21 -0800

Hi Dean,
At 20:06 04-03-2011, Dean Willis wrote:
>2007 issue of IEEE Spectrum included an article entitled "The Athens 
>Affair", subtitled "How Some Extremely Smart Hackers Pulled Off The 
>Most Audacious Cell-Network Break-in Ever". In short,

http://spectrum.ieee.org/telecom/security/the-athens-affair/0

>neither able to

There is a mailing list at https://www.ietf.org/mailman/listinfo/ietf-privacy

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 6 Mar 2011 21:55:59 -0500

I am rather skeptical.

At this point the secret is out and the potential of the Internet and the
Web is rather too well understood.

Documenting the privacy issues raised may well serve more to provide
dictators with ideas than actionable advice and even if the recommendations
are actionable there is no guarantee they will be acted on.

We really need to progress from looking at the effects we wish to achieve
and design technology that is designed to meet those ends.

On Sun, Mar 6, 2011 at 10:52 AM, Marc Petit-Huguenin <[email-masked]>wrote:

> > I just came across what may be old news to many of you. The July 2007
> issue of IEEE Spectrum included an article entitled "The Athens Affair",
> subtitled "How Some Extremely Smart Hackers Pulled Off The Most Audacious
> Cell-Network Break-in Ever". In short, perpetrators appear to have accessed
> the lawful-intercept component of mobile switches in-use, and were able to
> tap a lot of phones, including that of the Prime Minister of the host
> nation.  Apparently this was made easier by the fact that the user-interface
> for the LI component had not yet been installed, making it possible for the
> interceptions to go undetected for some time.
> >
> > This is just an example of a maxim: if we build nefarious mechanisms into
> systems, SOMEBODY is going to abuse them. Otherwise said: If you build in a
> back-door, don't be surprised when somebody sticks something in it. Sure,
> any meathead can slap a microphone on a window, order the withdrawal of a
> bunch of BGP routes, or cut the power to a switching center. There's not a
> lot we can do about that. But we can do a lot about a wide variety of "man
> in the middle" attacks, if we're willing to step up and confront the bullies
> out there, along with the misguided who don't understand why security
> back-doors are a two-edged sword, as dangerous to themselves as to their
> opposition. Sure, everybody wants their systems to be "secure" and their
> opposition's systems less so, but in the real world, everybody is somebody's
> opposition. The only way to be safe is to have universal protections. Start
> by locking yourself out. If that works, then it MAY stop the bad guys too.
> >
> > Every document we now produce has a "Security Considerations". I hereby
> propose the following extensions to that  section, such that each
> specification requiring a meaningful Security Considerations section MUST
> address the following:
> >
> neither able to understand nor alter the transmitted material without the
> explicit consent and awareness of the users. How are the principles of
> end-to-end privacy and integrity provided by the specification? Reasonable
> solutions might include any of our well-documented encryption and signature
> systems coupled with applicable key management mechanisms. Analysis within
> the specification should also describe the known limitations of the
> specification, such as susceptibility to hostile certificate authorities.
> Further, forthcoming IETF specifications MUST not allow plain-text
> transmission of anything within any protocol. Sign or cipher (or both, as
> appropriate) everything, all the time.
> >
> > 2) Privacy and Obscurity: We believe that observation of a traffic flow
> pr sequence of traffic flows should reveal as little information about the
> application or user of the application as possible to an intermediary who
> observes the traffic without the explicit consent and awareness of the user.
>  In principle, "deep packet inspection" should be completely useless, as
> should attempts by an intermediary to trace the end-user(s) to a specific
> physical location. How does the specification provide for obscuring the
> content of the application and the identity and location of users involved
> in the sequence?  Reasonable solutions might include things like TOR
> combined with TLS. Analysis within the specification should also describe
> known limitations of the specification, such as frequency and time domain
> analysis at a network-adjacent node, or dependency on interceptible
> dereferencing mechanisms like the DNS.
> >
> >
> infrastructure" than the end users do. I know the utilization on my TOR exit
> relay has been 100% for several months now, so there are clearly people who
> understand enough of the problem to be attempting  some sort of defense. And
> we have persons in authority who find open communication threatening and
> frequently "shutting down" access to parts of the net, such as LinkedIn,
> Facebook, Skype, Blackberry Messenger, or whatever they deem threatening on
> any given day. We can't keep them from turning off the whole Internet, but
> if we design protocols correctly, we can force them to choose between
> participating in the civilization of the Internet, ALL OF IT, or being
> completely isolated.
> >
> > If we do NOT act on this proposal, then our misguided leaders, censors,
> tyrants, and fools will continue to be able to piecemeal select which parts
> of the Internet they will allow, thereby manufacturing their own
> self-serving subsets of "the truth". At the same time, criminals will
> continue to exploit  protocol weaknesses to spam, spoof, steal, and subvert.
> And the Internet will not be the mechanism for peaceful economic expansion,
> prosperity, and interpersonal communication that it could be.
> >
> >
> > Much, I think, can be judged about respondents to this manifesto by the
> nature of their response. Many will quite reasonably say "This is hard to
> do". I agree; we can't expect immediate perfect answers, just as we know
> we've never been able to get perfect answers to most any security question,
> we know we will never produce perfect solutions for these issues. Others
> will say that these goals are undesirable. I suspect that these individuals
> are either proprietors of deep-packet-inspection tools, thieves, or
> accessories to the overbearing governments who employ and enable the
> afore-mentioned classes of miscreant. Others may agree wholeheartedly, but
> flinch at the political repercussions. To them, I say: Step up. No good deed
> goes unpunished, but at least the goal is worthwhile.  And it's probably
> safer than standing in front of a tank or a camel-cavalry charge, although
> less likely to get you remembered. Yet others may ask why this proposal is
> made now, rather than the first
> of

-- 
Website: http://hallambaker.com/

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Mar 2011 16:50:47 +0100

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:
> Excellent idea. Perhaps this should be plotted over jasmine tea 
> instead of coffee...
>
>
> 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
>
>

---

From: Ed Juskevicius <[email-masked]>
Date: Thu, 10 Mar 2011 12:29:57 -0500

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 <[email-masked]>wrote:

>> 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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 10 Mar 2011 10:24:16 -0800

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 10 Mar 2011 10:31:37 -0800

On 04/03/2011, at 8:06 PM, Dean Willis wrote:

[snip]

> 1)  Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users. How are th…

Encrypting *everything* means that all communications become exclusively two-party, and thus requires that you implicitly trust the party at the other end of the connection.

I trust both my government and my ISP much more than I trust many of the Web sites that I visit with my browser. 

Privacy researchers (like Balachander Krishnamurthy, who unearthed many of the liberties that Web sites take with privacy, leading to the current kerfuffle in the FTC and recent action by the EU) won't be able to verify how servers treat our data if it's all opaque. I think that's a much worse world than the one we live in today.

> 2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible…

This will have the effect of isolating some companies and countries from the Internet. Is that a good outcome?

[snip]

--
Mark Nottingham   http://www.mnot.net/

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 10 Mar 2011 12:50:36 -0600

+1

Thanks, Henry

On 3/10/11 12:24 PM, "Ted Hardie" <[email-masked]> wrote:

>     The system is less secure than it could be had
>    The system is more complex than it could be had
>    Being more complex, the risk of unintended security flaws in the
> system is       larger.
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Mar 2011 20:23:01 +0100 (MET)

> doing) designed these capabilities, rather than leave it to others do so."

Correct, these agencies are going to define and require capabilities
independent of what the IETF is doing.  So what.

We do not want that in our protocols, because we do not want any other
party besides those that are officially participating the communication
to be able to get at the contents of the communication -- without at least
one of the participating parties being aware of a wiretap.

Within our protocols, it is impossible to prevent that a rightful
participant shares his communication data with a law enforcement
agency.  Hopefully there is a warrent for permitting this or a very
severe imminent threat.  But the only point of weaknesses in protocols
itself is to be able to wiretap without asking any of the participants
for their consent and without getting it lawfully authorized (e.g. warrant).

Bottom line - lawful intercept can be done at the endpoints independent
of the protocol.  Protocol weaknesses or backdoors first of all are 
weaknesses with an extremely large abusive potential for both good
_and_ bad, and even the allegedly good are well known to regularly
abuse their powers (and if you are not aware that they're (ab)using
their powers, then there is no way to stop them from abusing their
power or to hold them responsible.

"Open your protocols to wiretapping"

is not very much different to folks when the enter a country that they
MUST refrain from talking to others in foreign languages, because it
might impair agents from some government organization (whoose potential
presence is not revealed to you) from following any conversations you
might be participating in.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Mar 2011 22:47:46 -0500

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.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Mar 2011 05:25:40 +0100 (MET)

> specialist trained cipher clerks and coms operators.

I don't think this is correct.

The end-to-end security model is actually the only one that did work,
provided that it could be used in an ad-hoc fashion PGP, SSH, WPA/WPA2
-- i.e. without any need to involve any third party, pay fees and go
through a very bureaucratic setup process and end up with a severely
constrained, lifetime-limited result.

Things that failed badly are those that are severly usability-impaired
for ad-hoc usage (such as TLS) or completely locked against ad-hoc usage
(such as S/MIME), simply because the technology completely ignored
how security works for humans in real life: it starts ad-hoc with a
leap-of-faith on initial encounter and trust develops over time
through memorizing experience of previous encounters.

The original SSH approach is really the most natural fit, and it just
worked out-of-the box for Linux installations (I realize I haven't
been installing Linux Distros for a couple of years ...)  Did this
change in the meantime?

A devastatingly large number of Web-Servers and WebShops has been
misapplying SSL/TLS.  And it takes Foolproof point-and-click exploits
such as Firesheep to make businesses move slighlty towards better
security from the irresponsible state they've been holding for
years in full awareness of their own negligence. 

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Mar 2011 00:03:35 -0500

1) WPA/WPA2 is not an end to end protocol by any stretch of imagination. It
is link layer security.

The fact that you would even try to pass off the special case of the ends of
the link being the ends of the communication suggests that you understand
how weak your case is here.

2) My argument was based on usage by the billion plus Internet users.

I don't think more than about 5% of Internet users have ever used one of the
protocols you mention. And of the people who install free encryption
add-ons, the number who actually go on to use them regularly
is infinitesimal.

Now that particular group are a pretty important group with pretty important
reasons for doing what they do. But from my perspective it was a mistake to
design Internet security so that it could only serve their needs and not the
needs of even a majority of Internet users.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Mar 2011 18:03:21 +0100 (MET)

Phillip Hallam-Baker wrote:
> 
> 1) WPA/WPA2 is not an end to end protocol by any stretch of imagination.
>    It is link layer security.

It is a 100% end-to-end security protocol.

A protocol that by design is not end-to-end security might be SMTPS.
which is why end-users are usually not even aware when and where it
is used.

> protocols you mention.

WPA/WPA2 (and formerly WEP) is likely used by >50% of the internet
users in Germany.  Based on court decisions (filesharing) about
liabilities for running open WLANs, _not_ to use WPA/WPA2 can be a pretty
expensive risk.

-Martin

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 Mar 2011 11:57:10 -0600

> It is a 100% end-to-end security protocol.

I'm reminded of those signs saying "Repent! The end is closer than you think!"

I think we have different ends in mind here. In the real-time community, we usually think of WPA2 as an "end to middle" security protocol, in that it doesn't protect the entire path from Alice to Bob unless both are running on the same ad-hoc wireless network.  It does protect the specific link, say from Alice to her access-point, but does nothing to keep the access point itself from mirroring the cleartext onto another port.

--
Dean

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Mar 2011 13:49:54 -0500

This is one of my bigger problems with so-called end to end security.

Contrary to what Ron wrote in his paper, Alice is NOT a Turing machine. She
is a person. And in the general case it is not even Alice who is the real
endpoint of the transaction.

The ends of a business transaction are corporations and/or people.

And what turns out to matter in government information systems is not really
the communication part of the problem at all. Its the document life-cycle.

Rather than put Bernard Manning in the Quantico brig we should put the
people who let a low level clerk have access to such a vast quantity of
information. We had the technology that could have prevented a low level
clerk from having the ability to download and redistribute that data, it was
not deployed.

End-to-end has been turned into an ideology and ideologies ALWAYS fail where
security is concerned.

Unless we have the endpoints implanted in the brains of the sender and
receiver we will never achieve true end-to-end security.

On Fri, Mar 11, 2011 at 12:57 PM, Dean Willis <[email-masked]>wrote:

> I think we have different ends in mind here. In the real-time community, we
> usually think of WPA2 as an "end to middle" security protocol, in that it
> doesn't protect the entire path from Alice to Bob unless both are running on
> the same ad-hoc wireless network.  It does protect the specific link, say
> from Alice to her access-point, but does nothing to keep the access point
> itself from mirroring the cleartext onto another port.
>
> --
> Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 Mar 2011 19:07:35 -0600

> This will have the effect of isolating some companies and countries from the Internet. Is that a good outcome?

You mean some third-world (or soon to be) junta-dictator might officially and deliberately cut their economy off from the world's communication networks, thereby insuring economic failure, rather than suffer the risk that their citizens might be exposed to external influence or use the Internet to complain about or conspire against their "lawful leaders", rather as North Korea has done?

I'm OK with that. It helps bring about their failure due to economic collapse rather than requiring outside force to stop their depredations, although it might take a few generations to work.

I'm also okay with air-dropping satellite terminals and television receivers to their victims, and with beaming high-power wireless signals across their borders in order to speed things up.

--
Dean

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Mar 2011 17:13:55 -0800

> I'm OK with that. It helps bring about their failure due to economic collapse rather than requiring outside force to stop their depredations, although it might take a few generations to work.

... compared to the much faster social changes that have been witnessed in places where there's been even partial exposure to external information, that seems like a poor outcome. Collapse is messy and very dangerous for the people you want to help.

> I'm also okay with air-dropping satellite terminals and television receivers to their victims, and with beaming high-power wireless signals across their borders in order to speed things up.

And how likely are those things to actually happen and have a measurable effect? Seriously. 

I have severe doubts about whether this is an appropriate and capable forum for making such weighty judgements. YMMV.

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Mar 2011 12:48:44 -0600

> ... compared to the much faster social changes that have been witnessed in places where there's been even partial exposure to external information, that seems like a poor outcome. Collapse is messy…

How likely are people in even the most restrictive regime to not have even partial exposure to outside information, no matter whether IETF protocol specifications have richer security considerations than we currently practice?

> And how likely are those things to actually happen and have a measurable effect? Seriously. 

Ever heard of the Voice of America program? Most developed nations have something similar. Did you see all the satellite dishes on the walls of houses in Cairo?

Now, this does raise an entirely different question more related to parallel efforts to make self-organizing ad-hoc networks useful. This is a really good effort, useful in everything from economic growth efforts like OLPC to recovering from a Japan-earthquake-style major disaster. We should probably be working on this sort of thing harder than we presently are.

> I have severe doubts about whether this is an appropriate and capable forum for making such weighty judgements. YMMV.

Well, we certainly shouldn't be  trying to decide which nations thrive and which collapse. But we ARE responsible for the security characteristics of our own protocols. We're quite willing to talk about security, and make protocol specifiers jump through intricate and mostly useless hoops in their spec writing, but we don't seem to be willing to put our "money where our mouth is."

For example, why are we still running our web sites on HTTP instead of HTTPS? If we only had the latter, it becomes much more difficult for MITMs to know whether a person communicating with the IETF web site is participating in the IETF process or just using us as a web proxy to talk to Facebook about The Revolution. If all traffic is encrypted, and if the apparent endpoint might or might not be a relay instead of the actual endpoint, then it's a whole lot harder for the MITM to separate wheat from chaff. Many of our protocols support this sort of obscuring, but our practice has been to disable the functionality through implementation choices.

On a related note, we've developed what we think is a secured mail protocol suite. Yet we don't use it, instead subjecting our list members (and more so the administrators) to having to deal with an endless barrage of spam. We probably don't use our secured mail protocol because it is too cumbersome. Maybe that should be a wake-up call for us to develop a better way to secure mail.

But instead of doing practical things that actually impact security, we endlessly debate things like the distribution-reuse flags for geolocation objects (which will be generally ignored by implementors) and write specifications like the Consent Framework for SIP that will most likely never be implemented.

Most critically, we've recognized that Internet users may have needs for privacy (which until recently has meant just encryption of data) and integrity (minimally, signing of data). It's time we recognize another fundamental principle: obscurity (hidden purpose of data). And having recognized these principles, we need to start taking much more aggressive steps in protocol design to assure that they are actually being met in a useful way.

We can start by:

1) deprecating the non-secured variant of every core protocol that has both secure and non-secure variants 

2) not writing any more protocols with secured and non-secured variants

3) analyzing existing protocols that are fundamentally non-secured and determine which, if any, security enhancements should be made normative 

4) Doing a much better job of really analyzing the security considerations of new work, taking fully into account the principles of privacy, integrity, and obscurity. Keep in mind that every protocol has the "good citizenship" responsibility not just of addressing these principles itself, but of also helping its fellow citizens meet them.

5) Incorporating the principles of Privacy, Integrity, and Obscurity directly into our core mission statement, into the very fabric of our belief system, just as "Liberté, égalité, fraternité" became the driving motto of the Third Republic of France, ending much of the abuse of Privilege that preceded the revolution.

--
Dean Willis

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Mar 2011 00:00:44 -0600

> And how likely are those things to actually happen and have a measurable effect? Seriously. 

From today's news, Cuba seems to be worried about it:

http://www.cnn.com/2011/WORLD/americas/03/12/cuba.alan.gross/index.html?eref=mrss_igoogle_cnn

--
Dean

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 14 Mar 2011 11:17:25 +0100

On 5 mrt 2011, at 5:06, Dean Willis wrote:

> 1)  Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users.

> 2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible

Privacy and obscurity are tools that cut both ways. It can protect legitimate communications from evil regimes, but it can also shield illegal behavior from the law, or privacy violations commited by applications, or services running in a browser from the user.

It also makes debugging orders of magnitude harder, uses more overhead and engergy and slows down the communication. (Especially in mobile networks where one end is on battery power and the extra round trips required to negotiate encryption and authentication are typically slow.)

As such, it would be a very big mistake to start encrypting ALL communication. Whether the applying these mechanisms is sufficiently beneficial to be worth the numerous downsides should be evaluated on a case-by-case basis. It's not the IETF's job to force vendors and users to do something that they would otherwise choose not to do.

You're trying to attack the problem from the wrong side, anyway: you assume using the large infrastractures that are easy to control by states and then try to add a layer of protection. It would be better to work around these infrastructures completely. Why is it that when I email my colleague two meters away, within easy wireless range, that the message goes through the servers of Google somewhere (not even sure in which country those are)?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2011 11:25:15 -0400

>It is a 100% end-to-end security protocol.

Because the IETF deals in Internet protocols (for the most part) e-t-e
secruity usually is interpreted to mean a protocol that can traverse routers.

Steve

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Mar 2011 11:16:17 -0500

> Privacy and obscurity are tools that cut both ways. It can protect legitimate communications from evil regimes, but it can also shield illegal behavior from the law, or privacy violations commited…

Shielding illegal activity from the law is a prime use case. if we consider that political discourse is an illegal activity under conditions that some authoritarians, supported by violence, call "the law".

As for a trojan service running on your computer being shielded: Nobody suggested that the applications API-calls to your transport layer have to be encrypted. I personally believe you should have full access to your own computer's innards. And I suspect that a great many trojans also communicate privately today, even though we're still putting our user's data out on public display.
> It also makes debugging orders of magnitude harder, uses more overhead and engergy and slows down the communication. (Especially in mobile networks where one end is on battery power and the extra r…

True, things have consequences. Someone on this thread emailed me a quote from Benjamin Franklin: "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Much can also be said about those who give up essential liberty in order to obtain a bit of convenience or a marginal increase in battery power.

Your argument is something akin to requiring people to not lock the doors on their homes, because not having the doors locked might make it easy for emergency services personnel to respond to a reported break-in.

As for overhead, someone else was kind enough to send me a link to tcpcrypt, which seems to offer a lighter-weight solution than TLS:

http://tools.ietf.org/html/draft-bittau-tcp-crypt-00

As I've said earlier in this thread: if our security tools are too heavy to use, we need to consider the possibility that we need new tools.

> As such, it would be a very big mistake to start encrypting ALL communication. Whether the applying these mechanisms is sufficiently beneficial to be worth the numerous downsides should be evaluate…

True, there are certain communications that are truly "broadcast in nature" and would be disserviced by requiring them to be encrypted. Many of them, however, would do well to be integrity-protected. Consider the harm that a rogue DHCP server can produce.

It IS the IETF's job to decide whether IETF protocols will be published with built-in back doors, especially when we know that by default said back doors will be generally left standing wide open and that most developers (and consequently users) will never bother to even try the more-secured "front door" and see if it works for them.

If we don't want security holes, we shouldn't build them into our protocols!

> You're trying to attack the problem from the wrong side, anyway: you assume using the large infrastractures that are easy to control by states and then try to add a layer of protection. It would be…

That's also a very good question, and I'm aware and supportive of efforts to make a fundamental change here. One thing that was brought to my attention during this conversation is "Mondonet":

http://www.mondonet.org

Self-organizing models have tremendous potential. Consider how important something like this could be for rescue efforts currently underway in Japan. Imagine how much better the communications could be if every cell phone switched over into a self-organizing ad-hoc mode and relayed messages peer-to-peer both between phones and back to whatever fixed infrastructure survives.

But that simple fact of the matter is that TODAY we have this large infrastructure called "The Internet" and that TODAY it is easily controlled by states and intercepted by criminals , and that TODAY people are using it to organize against abusive states and to carry out their private lives (financial or otherwise), and that TODAY people are being robbed, killed or otherwise suppressed  because our infrastructure leaks private data all over the place.

So, what are we going to do about today's networks for tomorrow, not for the next millennium?

--
Dean

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Mar 2011 16:23:14 +0100

I'm sorry I'm late, this thread was in my backlog.

On 12.03.2011 19:48, Dean Willis wrote:
> On a related note, we've developed what we think is a secured mail
> protocol suite. Yet we don't use it, instead subjecting our list members
> (and more so the administrators) to having to deal with an endless barrage
> of spam. We probably don't use our secured mail protocol because it is too
> cumbersome. Maybe that should be a wake-up call for us to develop a better
> way to secure mail.

What secured mail suite?  I have some difficulty in recognizing whether
you're talking about SMTP + Submission + DKIM + whatever else or some other
messaging system.  I agree that current Internet mail, with its one-figure
legitimate traffic percentage, is a conspicuous representative of IETF's hall
of shame.

> Most critically, we've recognized that Internet users may have needs for 
> privacy [...] And having recognized these principles, we need to start
> taking much more aggressive steps in protocol design to assure that they
> are actually being met in a useful way.

I also heartily agree with this, and with all the motivations that inspired
this thread.  However, I have difficulties resolving my feelings on this
point:  Freedom activists in my country bring out a whole load of grievances
every time Berlusconi attempts to restrict usage of wiretapping.  In facts,
this tool is a requirement for carrying out investigations at a sustainable cost.

I think the IETF must substantiate its position against wiretapping by
providing alternative practical means to counter crime.  Failing to do so
would recast ourselves as proposers of Utopian designs.  And, yes, after more
than a decade of spam supremacy, email would certainly be a convincing
test-bed for our ability at providing such alternative means.

> both secure and non-secure variants

Among SMTP variations, RFC 4409 is the more promising requisite for solving a
number of authentication issues.  Note that it conflicts with peer-to-peer
visions à la mondonet, though.

> 3) analyzing existing protocols that are fundamentally non-secured and
> determine which, if any, security enhancements should be made normative

While these are certainly correct, ensuring implementation and deployment is
also fundamental.  I accept and respect the limits of IETF's action, and
consider non-enforcement a key feature in the volunteer-oriented design that
is being carried out.  However, we should pay more attention to the full
protocol life cycle.

> 4) Doing a much better job of really analyzing the security considerations
> of new work, taking fully into account the principles of privacy,
> integrity, and obscurity. Keep in mind that every protocol has the "good
> citizenship" responsibility not just of addressing these principles
> itself, but of also helping its fellow citizens meet them.

I understand this as a recommendation to provide means for users of a
protocol --either another protocol or the "end" user-- to discover in some
meaningful way what are the relevant characteristics of the current
communication.  By "meaningful" I mean the opposite of those audible but
unidentifiable beeps that all too frequently infest work rooms :-)

> 5) Incorporating the principles of Privacy, Integrity, and Obscurity
> directly into our core mission statement, into the very fabric of our
> belief system, just as "Liberté, égalité, fraternité" became the driving
> motto of the Third Republic of France, ending much of the abuse of
> Privilege that preceded the revolution.

Yes, and, like for points 2-3 above, we must take care of how these
principles are understood by the community at large.  Skepticism,
opportunism, and thoughtlessness have spread too much.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 22 Mar 2011 08:35:49 -0700

> test-bed for our ability at providing such alternative means.

The IETF does not have a an official position "against" wiretapping. We
have RFC 2804 which is an IAB statement on it being out of scope for the
creation and maintenance of IETF standards.

The responsibility for the requirements is necessarily in the hands of
state actors whether we're in the US, Europe, China or Iran.

joel

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Mar 2011 12:53:56 -0500

> I'm sorry I'm late, this thread was in my backlog.

We now have an [email-masked] list for further discussion if you wish to join us  there.

> legitimate traffic percentage, is a conspicuous representative of IETF's hall

We have this whole S/MIME thing that nobody uses. We tried to replicate it to real-time communications, like SIP and Instant Messaging. Oddly enough, nobody uses it there either. Maybe that's because it doesn't deploy very well.

> this tool is a requirement for carrying out investigations at a sustainable cost.

I'm not necessarily against wiretapping. I think it's a great way to build a criminal enterprise, if that's your goal.

However, I am against explicitly designing exploitable weaknesses into our protocols. I'm even against implicitly designing in exploitable weaknesses by leaving compliance-test requirements for security as "SHOULD" strength issues, or by writing the specs in such a way that we can expect the security functions to never be implemented or used.

> providing alternative practical means to counter crime.  

Weak security doesn't counter crime -- it creates it. For example, the US government recently illegally tapped lots and lots of phone calls and Internet traffic at an AT&T switching center. Had the traffic been properly secured, this criminal behavior could have been prevented.

Do you want to counter crime, or prevent criminals from communicating with each other? One is laudable. The other is prior restraint of freedom of speech.

> Failing to do so

Well, it's better than nothing. It's got my spam load down to a bit less than 98% of my incoming mail.

But we can't expect every IETFer to SMTP-auth with the IETF server for every message they send to an IETF list. Nor can we detect whether remote domains used RFC 4409, nor can we filter on that knoweldge. Consequently, our lists get spammed.

Perhaps every server-to-server SMTP transmission should be authenticated and authorized. We tried this (authorizing intermediaries) with SIP's "Consent model".  See RFC 5360. That didn't work either; the genie was already out of the bag, and having too much fun running around in his pajamas.

> is being carried out.  However, we should pay more attention to the full

I believe that from a security perspective, the most important part of the protocol life cycle is the development and testing phase. People tend to rush right to deployment once something is "basically working". If "security" is deferred to a follow-on exercise, it just doesn't happen.

Consequently, we need to make sure that every protocol we write includes its security solutions in the base protocol, not in a layer to be added later. Phase 1 should be establishing a secured channel -- phase 2 is getting the application to work over that channel.

Perhaps we should just have Google host a Gmail-four-our-domain setup, have everybody use that, and preclude external email addresses from participation?

> unidentifiable beeps that all too frequently infest work rooms :-)

 It's your responsibility to lock your doors even if you have nothing to steal, because if criminals get used to thinking of all doors as locked they aren't likely to keep rattling doorknobs to check.

What I'm saying is that even if your traffic isn't "sensitive", that you should treat it as if it were. This makes the traffic for people who ARE worried about being overheard not stand out. It's your responsibility to make your traffic look like gibberish to an intercepter, so that  MY traffic (which looks like gibberish even when not encrypted) won't draw undue attention. Be a good neighbor, and help me blend in!

> opportunism, and thoughtlessness have spread too much.

That's a great tripartate slogan for the counter-revolution. I would happily buy a reasonable T-shirt that proclaims "Skepticism, Opportunism, Thoughtlessness!"

--
Dean

---

From: SM <[email-masked]>
Date: Tue, 22 Mar 2011 21:52:58 -0700

Hi Alessandro,
>legitimate traffic percentage, is a conspicuous representative of IETF's hall

There are many things that might be suitable for the IETF's hall of 
shame but this is not one of them.  Many years ago, a research group 
about anti-spam was set up.  That was one way for the IETF to respond 
to the problem.

There are technical problems and social or political problems.  The 
IETF can only address the technical problems.  It is up to the people 
who adopt the technical solutions to address the social and political 
problems.  They do not do that.  Instead, they pretend, or assume out 
of ignorance, that the IETF has solved all the problems and the magic 
of technology will do the rest.

Sometimes the technical problem can only be addressed by making a 
social or political choice.  The IETF could turn that one-figure 
percentage into two if there was consensus on what the choice should be.

At 10:53 22-03-2011, Dean Willis wrote:
>Perhaps we should just have Google host a Gmail-four-our-domain 
>setup, have everybody use that, and preclude external email 
>addresses from participation?

That's an excellent idea. :-)  I prefer not to participate.

Regards,
-sm

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Mar 2011 09:02:55 +0200

On Mar 23, 2011, at 6:52 AM, SM wrote:

> The IETF can only address the technical problems. 

This is an argument I often hear. I do, however, believe that you cannot see technology in isolation. 

However, in many cases the technology, regulatory environment, business aspects, and the social context gets mixed together. 
Please have a look at: http://tools.ietf.org/html/draft-morris-policy-cons-00

Ciao
Hannes

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 23 Mar 2011 16:15:53 +0100

On 22.03.2011 18:53, Dean Willis wrote:
> Weak security doesn't counter crime -- it creates it. For example, the US
> government recently illegally tapped lots and lots of phone calls and
> Internet traffic at an AT&T switching center. Had the traffic been
> properly secured, this criminal behavior could have been prevented.
> 
> Do you want to counter crime, or prevent criminals from communicating with
> each other? One is laudable. The other is prior restraint of freedom of
> speech.

Not surprisingly, criminals are about as gullible as honest users.  They
record on the phone phrases that can be used in a trial to prove their guilt
before a court.  The symmetry-breaking originates from the commonly held
assumption that prosecuting criminals is useful to keep the community in an
orderly state.  As humans, our job is to improve the definition of community
so that that works with current technologies.  That is to say, although the
community is a self-defining entity, since we recognize it, we can and must
bring some technical consistency in its definition.

Let me quote SM here,
>. There are technical problems and social or political problems.  The IETF
>. can only address the technical problems.  It is up to the people who adopt
>. the technical solutions to address the social and political problems.
>. They do not do that.  Instead, they pretend, or assume out of ignorance,
>. that the IETF has solved all the problems and the magic of technology will
>. do the rest.

It is harder to retro-fit policy issues in an already designed protocol.
However, that's the way things go.  It would have been better to design SMTP
being well aware of spam.  We didn't, and hence cannot claim that it is not
our problem if users fail to address our tentative remedies.

> But we can't expect every IETFer to SMTP-auth with the IETF server for
> every message they send to an IETF list. Nor can we detect whether remote
> domains used RFC 4409, nor can we filter on that knoweldge. Consequently,
> our lists get spammed.

SMTP-AUTH could also be used to authenticate relays of well identified
traffic, such as mailing lists or newsletters.  It is not a problem for this
list, which is wonderfully maintained.  Use of submission could be certified
according to Section 2.4.4 of RFC 5451; I, for one, don't do so in order to
avoid revealing the authenticated ID, as it can be used in distributed
dictionary attacks.  DKIM and SPF provide something quite similar to
authentication, possibly simpler and slightly more used than S/MIME.

> Perhaps every server-to-server SMTP transmission should be authenticated
> and authorized. We tried this (authorizing intermediaries) with SIP's
> "Consent model".  See RFC 5360. That didn't work either; the genie was
> already out of the bag, and having too much fun running around in his
> pajamas.

Yes, explicit consensus is also mandated by EU privacy rules.  Perhaps, we
should set up a mechanism to automatically grant consensus.  At least, we
would then be able to easily identify the corresponding message stream.

Of course, the need to authenticate will not be felt until it is possible to
deliver mail without it.  That raises the issue of how can you authenticate a
client with no prior arrangements, as required by SMTP.  Thus, we are back to
the definition of community, and that's why I consider mail a good test- bed.

> I believe that from a security perspective, the most important part of the
> protocol life cycle is the development and testing phase. People tend to
> rush right to deployment once something is "basically working". If
> "security" is deferred to a follow-on exercise, it just doesn't happen.

But that won't help if the protocol is not deployed.  Requirements analysis,
promotion, deployment, training, and education are equally important.

> Consequently, we need to make sure that every protocol we write includes
> its security solutions in the base protocol, not in a layer to be added
> later. Phase 1 should be establishing a secured channel -- phase 2 is
> getting the application to work over that channel.

Ideally, yes.  However, if we manage to push the genie back into the bottle,
we may end up with a generic recipe for securing protocols after-the-fact.

> Perhaps we should just have Google host a Gmail-four-our-domain setup,
> have everybody use that, and preclude external email addresses from
> participation?

Walled gardens and private enclosures are an obvious alternative to
democracy.  I think we'd prefer free range humans over intensive (battery)
people.  The boundary is quite fuzzy, though, and that solution is good as
far as Google /is/ a community.

On a related point, is the end-users' computing equipment --possibly
including their brains-- an integral part of their personal belonging, or is
it the property of some private/public enterprise?  I know this is not a
technical question, but if the IETF has to address the issue of retro-fitting
privacy into communication protocols, it had better know whether to target
Google or their users.

The whole standardization process assumes a community with certain
characteristics, that supports such work and deploys its results.  The IETF
sometimes adapts to community changes, retains sound principles, sometimes
resists yielding up to the market, tracks the outcomes of its work, but does
not structurally resonate with the community because of those social/
political barriers.

> That's a great tripartate slogan for the counter-revolution. I would
> happily buy a reasonable T-shirt that proclaims "Skepticism, Opportunism,
> Thoughtlessness!"

Now that you've said it, I'd buy it too :-)

This sort of "general theory" considerations still belong to this list.

---

From: todd glassey <[email-masked]>
Date: Wed, 23 Mar 2011 08:43:16 -0700

> This is an argument I often hear. I do, however, believe that you cannot see technology in isolation.

That's because you are being a political animal and not a pure 
technologist here which violates the charter of the IETF in spades.

If the IETF is only set up to standardize technology then it cannot 
refuse to accept anything, further its members who try and block 
protocol's standardization regularly commit antitrust and TI by 
sabotaging various initiatives, and IMHO they need to be formally 
spanked (by lawyers) and sent to bed with no supper. There is no 
political or legal activity of the IETF in its standardization practice 
and it cannot implement social policy around what it standardizes and 
doesn't IMHO.
> Please have a look at: http://tools.ietf.org/html/draft-morris-policy-cons-00
only in the limited world of Social Networking...

Todd Glasssey

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Mar 2011 14:48:37 +0200

Hi Joel, 

RFC 2804 "IETF Policy on Wiretapping" was written by the IESG and the IAB.

From the abstract: 

Security protocols are in general designed to prevent wiretapping (in certain threat models, i.e. depending on where you consider the adversary is).

Ciao
Hannes