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

[Hannes Tschofenig]

I just notice your mail and thought I should respond given that you may have 
misunderstood something in this email conversation or in one of my responses. 

When a working group works on a specific problem then they get requirements 
from many different sources. Some of these requirements may be purely technical 
(such as performance aspects, encoding related questions, etc.) but there are 
also requirements that come from the desire to meet certain deployment 
constraints. Often protocols build on top of something existing; they do not 
make the assumption of a clean slate. By doing this they take business models 
into consideration, and consider a certain type of responsibility sharing. 
There may also be regulatory actions that influenced the work. 
http://tools.ietf.org/html/draft-morris-policy-cons-00 summarize these 
observations. It is not an IAB document but, as the filename indicates, an 
individual submission. The authors are soliciting input from the IETF community 
on the document and to share their protocol development experience with us. 

In any case, there are many requirements and the large number of guidelines we 
have protocol developers reflect this. Protocol design is not easy. Since a 
single person typically does not have the complete range of expertise needed we 
make use of directorates as well in the development of high-quality 
specifications. 

Despite all these different sources for requirements the actual result (the 
output of the working group) is a technical specification. It may provide 
background information, instructions for implementers or for those who deploy. 

The IAB and ISOC documents you mentioned in your other mails are slightly 
different. IAB documents, for example, may provide broader architectural 
advice. RFC 2804 "IETF Policy on Wiretapping" is such a document (written by 
IESG/IAB). 
Again other documents concern the core role of the IAB, such as the RFC Editor 
and IANA.

You like to call everything "politics" particularly if you do not like a 
certain argument. This is not a particularly useful approach since it does not 
help me (and maybe others) to get insight into the argument you are trying to 
make. 

Ciao
Hannes
(speaking for myself as an individual contributor to the IETF standardization 
process) 

On Mar 23, 2011, at 5:43 PM, todd glassey wrote:

> On 3/23/2011 12:02 AM, Hannes Tschofenig wrote:
>> 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.
> 
> 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.
>> 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
> only in the limited world of Social Networking...
> 
> Todd Glasssey
> 
> 
>> Ciao
>> Hannes
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Phillip Hallam-Baker]

Todd,

This is totally confused and you are completely wrong.

Under the Federal Election Campaign
Act,
an organization becomes a "political committee" by receiving contributions
or making expenditures in excess of $1,000 for the purpose of influencing a
federal election
[Source Wikipedia]

Since neither the IETF nor ISOC has any interest in influencing a federal
election, nor does it engage in any activity intended to do so, it is not a
political committee under the terms of the act.



On Mon, Apr 11, 2011 at 4:56 PM, todd glassey wrote:

> On 3/23/2011 12:02 AM, Hannes Tschofenig wrote:
>
>> 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.
>>
> Yeah - sure you can... if you want to be totally about the original design
> and practice of the IETF and its vision. It was built to advance protocol
> standardization and not to decide what protocols it would allow on the
> Internet and which it wouldn't.  But  lately many have forgotten this and
> are using the IETF as a formal lobby for technological policy advancement
> and that's a no-no.
>
> Bluntly the IETF members are becoming more and more aggressively
> politically and this statement is based on IAB and other publication on what
> the IETF does and does not allow through its frameworks. In doing so their
> statements about allowing protocols or not allowing protocols to be
> standardized based on their stated perception of "what damages the Internet"
> or what they personally want to see as a "free access to all information and
> ideas" model, creates a real serious divergence from the Standards Practice
> this organization was set up as, and IMHO is one which is designed clearly
> to destroy global Intellectual Property law and practice.
>
>  However, in many cases the technology, regulatory environment, business
>> aspects, and the social context gets mixed together.
>>
> No Hannes  - it doesn't unless the Chair allows it to - meaning that the
> Chair in this instance has allowed political materials to be fielded (filed
> in this instance) into the IETF and trust me I am already filing a formal
> complaint with the Treasury about ISOC's becoming a formal PAC and its
> locking out protocol efforts based on its own desires therein...
>
>
> http://tools.ietf.org/html/draft-morris-policy-cons-00
>
>
> I suggest that the Chair immediately post a formal statement that the IETF
> is a-political and will not do anything but standardize technology.  Also
> that ONLY technology drafts can be accepted since the IETF is part of ISOC
> and not registered as a political PAC or Lobbying Agency which it clearly
> has become in direct violation of the NTIA MOU which gave it (ISOC and its
> ARIN) the real power.
>
>
> Todd Glassey
>
> Please have a look at:
> http://tools.ietf.org/html/draft-morris-policy-cons-00
>
>> Ciao
>> Hannes
>>
>
> Hannes - this is the issue with the IETF and the gross number of flaming
> idiots inside of it. The IETF is not a Social Reform Agency, nor is it a
> freaking political action group since its financial filings prevent this.
>
> Todd Glassey
>
>  ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[todd glassey]

On 3/23/2011 12:02 AM, Hannes Tschofenig wrote:

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.
Yeah - sure you can... if you want to be totally about the original 
design and practice of the IETF and its vision. It was built to advance 
protocol standardization and not to decide what protocols it would allow 
on the Internet and which it wouldn't.  But  lately many have forgotten 
this and are using the IETF as a formal lobby for technological policy 
advancement and that's a no-no.


Bluntly the IETF members are becoming more and more aggressively 
politically and this statement is based on IAB and other publication on 
what the IETF does and does not allow through its frameworks. In doing 
so their statements about allowing protocols or not allowing protocols 
to be standardized based on their stated perception of "what damages the 
Internet" or what they personally want to see as a "free access to all 
information and ideas" model, creates a real serious divergence from the 
Standards Practice this organization was set up as, and IMHO is one 
which is designed clearly to destroy global Intellectual Property law 
and practice.

However, in many cases the technology, regulatory environment, business 
aspects, and the social context gets mixed together.
No Hannes  - it doesn't unless the Chair allows it to - meaning that the 
Chair in this instance has allowed political materials to be fielded 
(filed in this instance) into the IETF and trust me I am already filing 
a formal complaint with the Treasury about ISOC's becoming a formal PAC 
and its locking out protocol efforts based on its own desires therein...


http://tools.ietf.org/html/draft-morris-policy-cons-00


I suggest that the Chair immediately post a formal statement that the 
IETF is a-political and will not do anything but standardize 
technology.  Also that ONLY technology drafts can be accepted since the 
IETF is part of ISOC and not registered as a political PAC or Lobbying 
Agency which it clearly has become in direct violation of the NTIA MOU 
which gave it (ISOC and its ARIN) the real power.



Todd Glassey
Please have a look at: 
http://tools.ietf.org/html/draft-morris-policy-cons-00

Ciao
Hannes


Hannes - this is the issue with the IETF and the gross number of flaming 
idiots inside of it. The IETF is not a Social Reform Agency, nor is it a 
freaking political action group since its financial filings prevent this.


Todd Glassey

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Hannes Tschofenig]

Hi Joel, 

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

>From the abstract: 

   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.

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


On Mar 22, 2011, at 4:35 PM, Joel Jaeggli wrote:

> On 3/22/11 8:23 AM, Alessandro Vesely wrote:
>> 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.
> 
> 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
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[todd glassey]

On 3/23/2011 12:02 AM, Hannes Tschofenig wrote:

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.


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.

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

only in the limited world of Social Networking...

Todd Glasssey



Ciao
Hannes

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Alessandro Vesely]

On 22.03.2011 18:53, Dean Willis wrote:
> On Mar 22, 2011, at 10:23 AM, Alessandro Vesely wrote:
>> I think the IETF must substantiate its position against wiretapping by
>> 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.

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.

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

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

[Hannes Tschofenig]

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[SM]

Hi Alessandro,
At 08:23 22-03-2011, Alessandro Vesely wrote:

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.


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 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dean Willis]

On Mar 22, 2011, at 10:23 AM, Alessandro Vesely wrote:

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

We now have an obscurity-inter...@ietf.org list for further discussion if you 
wish to join us  there.

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

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.


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

> I think the IETF must substantiate its position against wiretapping by
> 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
> 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.
> 
>> We can start by:
>> 
>> 1) deprecating the non-secured variant of every core protocol that has
>> 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.

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.

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

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 

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

[Joel Jaeggli]

On 3/22/11 8:23 AM, Alessandro Vesely wrote:
> 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.

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Alessandro Vesely]

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.

> We can start by:
> 
> 1) deprecating the non-secured variant of every core protocol that has
> 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.

> 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

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.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dean Willis]

On Mar 14, 2011, at 5:17 AM, Iljitsch van Beijnum wrote:
> 
> 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.

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 round trips required to 
> negotiate encryption and authentication are typically slow.)


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

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

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Iljitsch van Beijnum]

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)?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dean Willis]

On Mar 11, 2011, at 7:13 PM, Mark Nottingham wrote:
> 
>> 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. 


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___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dean Willis]

On Mar 11, 2011, at 7:13 PM, Mark Nottingham wrote:

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

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?


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

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 al

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

[Mark Nottingham]

On 11/03/2011, at 5:07 PM, Dean Willis wrote:

> 
> On Mar 10, 2011, at 12:31 PM, Mark Nottingham wrote:
>>> 
>> 
>> 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.

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


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



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dean Willis]

On Mar 10, 2011, at 12:31 PM, Mark Nottingham wrote:
>> 
> 
> 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___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Phillip Hallam-Baker]

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  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 
> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>>>
>>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>
>
> __

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

[Henry Sinnreich]

+1

Thanks, Henry


On 3/10/11 12:24 PM, "Ted Hardie"  wrote:

> On Thu, Mar 10, 2011 at 9:29 AM, Ed Juskevicius  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 
>> 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@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Mark Nottingham]

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

[snip]

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

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

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/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Ted Hardie]

On Thu, Mar 10, 2011 at 9:29 AM, Ed Juskevicius  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 
> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Ed Juskevicius]

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 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Harald Alvestrand]

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Phillip Hallam-Baker]

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

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/04/2011 08:06 PM, Dean Willis 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.
> >
> > 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 Inter

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

[SM]

Hi Dean,
At 20:06 04-03-2011, Dean Willis 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,


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


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


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

Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Marc Petit-Huguenin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/2011 12:52 PM, 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.

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
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk10DhYACgkQ9RoMZyVa61d4cwCgk7G6QZV1s/FFa/DLhk1Y1B9o
fCYAoJiKZuuAo5t8eCnOkqHieCfkL2rL
=XA6v
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dean Willis]

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Scott W Brim]

On Sun, Mar 6, 2011 at 10:52 AM, Marc Petit-Huguenin wrote:

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

I am told that http://www.cafeslavia.cz/ was a popular hangout for Czech
revolutionaries.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Marc Manthey]

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/04/2011 08:06 PM, Dean Willis 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.


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

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

[Marc Petit-Huguenin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/04/2011 08:06 PM, Dean Willis 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.
> 
> 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 weak

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

[Hannes Tschofenig]

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dean Willis]

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 mani