Subject: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

From: Dean Willis <[email-masked]>
Date: Thu, 5 Sep 2013 19:17:44 -0500

This is bigger than the "perpass" list.

I suggested that the surveillance/broken crypto challenge represents "damage to the Internet". I'm not the only one thinking that way.

I'd like to share the challenge raised by Bruce Schneier in:

http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying

To quote:

-----------
We need to know how exactly how the NSA and other agencies are subverting routers, switches, the internet backbone, encryption technologies and cloud systems. I already have five stories from people like you, and I've just started collecting. I want 50. There's safety in numbers, and this form of civil disobedience is the moral thing to do.

Two, we can design. We need to figure out how to re-engineer the internet to prevent this kind of wholesale spying. We need new techniques to prevent communications intermediaries from leaking private information.

We can make surveillance expensive again. In particular, we need open protocols, open implementations, open systems – these will be harder for the NSA to subvert.

The Internet Engineering Task Force, the group that defines the standards that make the internet run, has a meeting planned for early November in Vancouver. This group needs dedicate its next meeting to this task. This is an emergency, and demands an emergency response.
------------

The gauntlet is in our face. What are we going to do about it?

--
Dean Willis

---

From: Lucy Lynch <[email-masked]>
Date: Thu, 5 Sep 2013 17:46:07 -0700 (PDT)

> I suggested that the surveillance/broken crypto challenge represents "damage to the Internet". I'm not the only one thinking that way.

an additional call to action can be found here:

http://www.newamerica.net/pressroom/2013/statement_oti_statement_on_new_leaks_of_nsa_defeating_encryption_technology_3

"In the interim, technologists need to take a hard look at how to 
reengineer the Internet to avoid this type of massive undermining of our 
privacy rights. Our current trajectory is toward a more fractured, less 
safe Internet, and only major, meaningful reforms will restore trust and 
prevent even more detrimental outcomes."

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Sep 2013 13:36:23 +1200

I'm sorry, I don't detect the emergency.

I'm not saying there's no issue or no work to do, but what's new about
any of this?

Was PRISM a surprise to anyone who knew that the Five Eyes sigint
organisations have been cooperating since about 1942 and using
intercontinental data links since 1944)? Was Xkeyscore a surprise
to anyone who's been observing the whole Big Data scene? Is any
ISP or router vendor actually unaware of the security issues in
routers? Aren't most of them o/s implementation issues in any case?
Hasn't the IETF been working on BGP4 security for quite a while now?

I'm very glad we did RFC 1984 and RFC 2804 when we did, but it's
probably more important that we did RFC 3552. We certainly need
to apply it.

I am against any panic response to the hype. If someone can identify
any specific, new, protocol-based threats in the recent media stories,
that would be worth an I-D and appropriate IETF action.

Regards
   Brian Carpenter

On 06/09/2013 12:46, Lucy Lynch wrote:
>> I suggested that the surveillance/broken crypto challenge represents
>> "damage to the Internet". I'm not the only one thinking that way.
> 
>> We need to know how exactly how the NSA and other agencies are
>> subverting routers, switches, the internet backbone, encryption
>> technologies and cloud systems. I already have five stories from
>> people like you, and I've just started collecting. I want 50. There's
>> safety in numbers, and this form of civil disobedience is the moral
>> thing to do.
>>
>> Two, we can design. We need to figure out how to re-engineer the
>> internet to prevent this kind of wholesale spying. We need new
>> techniques to prevent communications intermediaries from leaking
>> private information.
>>
>> We can make surveillance expensive again. In particular, we need open
>> protocols, open implementations, open systems – these will be harder
>> for the NSA to subvert.
>>
>> The Internet Engineering Task Force, the group that defines the
>> standards that make the internet run, has a meeting planned for early
>> November in Vancouver. This group needs dedicate its next meeting to
>> this task. This is an emergency, and demands an emergency response.
>> ------------
>>

---

From: "cb.list6" <[email-masked]>
Date: Thu, 5 Sep 2013 19:15:34 -0700

>
>
> To quote:
>
> -----------
> We need to know how exactly how the NSA and other agencies are subverting
routers, switches, the internet backbone, encryption technologies and cloud
systems. I already have five stories from people like you, and I've just
started collecting. I want 50. There's safety in numbers, and this form of
civil disobedience is the moral thing to do.
>
> Two, we can design. We need to figure out how to re-engineer the internet
to prevent this kind of wholesale spying. We need new techniques to prevent
communications intermediaries from leaking private information.
> We can make surveillance expensive again. In particular, we need open
protocols, open implementations, open systems – these will be harder for
the NSA to subvert.
>
> The Internet Engineering Task Force, the group that defines the standards
that make the internet run, has a meeting planned for early November in
Vancouver. This group needs dedicate its next meeting to this task. This is
an emergency, and demands an emergency response.

Is there a standards gap or an implementation gap?

All Tor, all TLS, all PGP,  all DANE all the time?

And dont forget about this
http://www.zdnet.com/nokia-hijacks-mobile-browser-traffic-decrypts-https-data-7000009655/

I like this post below, just accept the risk that there is no expectation
of privacy. The snoops have optical taps and all the private keys.  And the
T&Cs for most public email services, social networks,  maps, hospitals,
airport wifi... make it clear your data is not private.

http://www.schneier.com/blog/archives/2013/09/our_newfound_fe.html

CB

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Sep 2013 23:04:17 -0400

>> I'd like to share the challenge raised by Bruce Schneier in:

I thought it was a great call to action.   Is Bruce coming to Vancouver?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Sep 2013 23:08:12 -0400

> I'm sorry, I don't detect the emergency.

I think we all knew NSA was collecting the data.   Why didn't we do something about it sooner?   Wasn't it an emergency when the PATRIOT act was passed?   We certainly thought it was an emergency back in the days of Skipjack, but then they convinced us we'd won.   Turns out they just went around us.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Sep 2013 23:11:00 -0400

> that would be worth an I-D and appropriate IETF action.

As I have suggested to several people, we can turn lemons into lemonade.

The NSA has conspicuously failed to keep the state secrets of the US
secret. Clapper should be forced to resign or be sacked. The NSA is too big
to keep secrets.

But they have also failed on the technical mission to develop and deploy
technology to protect secrets. They have harassed people trying to deploy
strong crypto, myself included. I don't think it is exactly a coincidence I
had my car searched three times on a round trip between Geneva and London
when I started working on security. Or that the harassment suddenly stopped
after I used my family connections to make a complaint.

I knew that the CERN hub was compromised when I was at CERN. I have known
that the System-X telephone system in the UK is expressly designed to allow
any telephone handset in the UK to be turned into a passive room bug. But
until the Snowden materials were released I have found it difficult to
convince other people of the extent of those capabilities or the risks that
they pose.

The CIA has finally admitted that they were behind the Operation Ajax coup
that replaced democracy in Iran with a convenient dictator. At least until
the rabble rouser the US embassy hired to set up the riots that brought the
government down toppled the convenient despot in the 1979 revolution. What
has not yet come out is that the coup was only possible because the NSA had
cracked the Iranian ciphers and that is how the CIA knew which army
officers might be sympathetic.

So I don't think that the unrestricted ability to read other gentlemen's
mail is quite the boon that some imagine.

Now I also have known for over twenty years that when some of us were
trying to bring the East German government down because the communist
system was a disgrace to humanity my own Prime Minister was meeting with
Gorbachev begging him to send in the tanks and stop the regime collapsing.

There are many things that I know and have known but I don't generally
mention because mentioning such things without the ability to prove them
tends to make you look like a bloody fool. Thanks to Snowden I can now
confirm that HEPNET was tapped at CERN without looking a bloody fool.

S/MIME is almost what we need to secure email. What is missing is an
effective key discovery scheme. We could add that and add Ben Laurie's
Certificate Transparency and have a pretty good start on a PRISM Proof
email scheme.

What we lack is not the technology, it is demand for deployment. Snowden
supplies that demand in two ways. First by revealing the extent of NSA and
GCHQ surveillance, second by exposing the fact that the agency is badly,
sloppily run and likely riddled with Snowdens from Russia, China and
goodness knows where else.

At this point the closure of PRISM and BULLRUN and the rest is
inevitable.  Likely not under this President but the next won't owe the
same debts.Clapper has to go and so has Alexander. Heads have to roll when
there is a security breach caused by such abject incompetence and a failure
of the NSA mission to protect US government secrets, especially their own.

What we can achieve instead is to secure the Internet. I don't care what
bogeyman is that motivates people to do what is necessary provided that
they do it. We have to lock down the nuclear power stations that have
control systems based on MODBUS and no authentication controls whatsoever.
We have to lock down electricity, water, gas.

The mission here is to make our countries safe. Making our countries unsafe
to protect the ability of idiots to play wargames is notthe act of a
patriot, it is the act of a traitor.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Sep 2013 15:19:30 +1200

> I think we all knew NSA was collecting the data.   Why didn't we do something about it sooner?   Wasn't it an emergency when the PATRIOT act was passed?   We certainly thought it was an emergency b…

Tell me what the IETF could be doing that it isn't already doing.

I'm not talking about what implementors and operators and users should
be doing; still less about what legislators should or shouldn't be
doing. I care about all those things, but the question here is what
standards or informational outputs from the IETF are needed, in addition
to what's already done or in the works.

I don't intend that to be a rhetorical question.

     Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 05 Sep 2013 20:23:07 -0700

On 9/5/2013 8:08 PM, Ted Lemon wrote:
>   they convinced us we'd won

We've done quite a sales job on ourselves, also.

Remember the IAB tech plenary that declared protocols dead, because the 
client is downloaded from the server?  Think about that, in the light of 
recent revelations about compromised service providers.

That is, contrast it with truly distributed and independent clients, 
where the protocol defines a controlled and publicly vetted interface 
between the client and the server.  The former makes the client a 
semantic slave to the server.  The latter makes clients semantically 
independent and easily able to layer things on top of the services 
provided by the server.  Such things as, ummm, encryption.

Clients downloaded from the server, during a session, are extremely 
convenient.  But they can represent an interesting violation of the 
end-to-end "principle", by placing too much into the infrastructure.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Sep 2013 15:28:28 +1200

On 06/09/2013 15:11, Phillip Hallam-Baker wrote:
...
> Certificate Transparency and have a pretty good start on a PRISM Proof

OK, that's actionable in the IETF, so can we see the I-D before
the cutoff?

> 
> What we lack is not the technology, it is demand for deployment. 

Exactly, and that is not actionable in the IETF.

    Brian

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Sep 2013 19:30:53 -0800

On 9/5/13 7:19 PM, Brian E Carpenter wrote:
> I'm not talking about what implementors and operators and users
> should be doing; still less about what legislators should or
> shouldn't be doing. I care about all those things, but the question
> here is what standards or informational outputs from the IETF are
> needed, in addition to what's already done or in the works.

There are pretty clearly still some serious problems around
crypto and usability.  I tend to look at those problems as
largely being implementation questions.  But still, it may
be the case that there's work that can be done to protect
leaking what might be called signaling (or metadata).

This assumes, of course, that current crypto technology
(ciphers, anyway) is sufficient, which Schneier seems to
think is the case.

Melinda

---

From: Vinayak Hegde <[email-masked]>
Date: Fri, 6 Sep 2013 09:02:49 +0530

> As I have suggested to several people, we can turn lemons into lemonade.

While it is nice to do a dedication of this meeting to the SA surveillance,
I do not see us solving any issue here. It is merely a "feel-good" measure
without real impact.

First, the IETF always had a bias for action. We always respect "rough
consensus and running code". So far I have not seen not I-Ds and drafts to
fix the privacy and encryption issues on this thread.

Second, technology can never fix what is essentially a political problem.
for eg. We mandate strong security protocols and end-to-end encryption in
HTTP(S) by default. Lets assume all browsers implement this and do this
perfectly without software flaws. All the NSA has to do is to compromise
the other endpoint (controlled by ACME major corp). ACME gives over the
encryption keys and access to all the unencrypted data to the NSA. So now
what are we going to do. The IETF can make an political statement by taking
a stand but that may mean nothing in reality when the laws are weak.
Another example is when you have encrypted your drive and do not want to
hand over the keys as it has some personal (and possibly incriminating
evidence). In several countries you can be held in jail indefinitely (with
obvious renewals of sentences) until you hand the keys over[1]. So in
summary, technology cannot solve political and legal issues. At best it can
make it harder. But in this case maybe not even that.

-- Vinayak
1. http://www.infoq.com/presentations/HTTP-Performance by Poul Henning-Kamp

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Sep 2013 23:32:54 -0400

> OK, that's actionable in the IETF, so can we see the I-D before

Why is that discussion of this nailed to the cycle of IETF meetings?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Vinayak Hegde <[email-masked]>
Date: Fri, 6 Sep 2013 09:07:19 +0530

On Fri, Sep 6, 2013 at 9:02 AM, Vinayak Hegde <[email-masked]> wrote:

> While it is nice to do a dedication of this meeting to the SA
> surveillance, I do not see us solving any issue here. It is merely a
> "feel-good" measure without real impact.
>

Also when people talk about NSA surveillance, they often talk about servers
and PCs which serve as endpoints. The NSA seems to have figured out that
the weaker points are in the intermediate routers and bugs in the
software[1]. If anything, network engineers and operations should update
their software more regularly[1].

-- Vinayak
1. http://www.wired.com/threatlevel/2013/09/nsa-router-hacking/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Sep 2013 23:42:48 -0400

> OK, that's actionable in the IETF, so can we see the I-D before

Yes, the ID should be out next week together with the request for a BOF on
PRISM Proof email which has a shorter fuse.

> Exactly, and that is not actionable in the IETF

On the contrary. taking advantage of a marketing opportunity is certainly
something the IETF can do.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Sep 2013 23:56:14 -0400

> Why is that discussion of this nailed to the cycle of IETF meetings?

It is not. I raised the challenge over a week ago in another forum. Last
thing I would do is to give any institution veto power.

The design I think is practical is to eliminate all UI issues by insisting
that encryption and decryption are transparent. Any email that can be sent
encrypted is sent encrypted.

So that means that we have to have a key distribution infrastructure such
that when you register a key it becomes available to anyone who might need
to send you a message. We would also wish to apply the Certificate
Transparency approach to protect the Trusted Third Parties from being
coerced, infiltrated or compromised.

Packaging the implementation is not difficult, a set of proxies for IMAP
and SUBMIT enhance and decrypt the messages.

The client side complexity is separated from the proxy using Omnibroker.

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Sep 2013 13:59:54 +0900

> (ciphers, anyway) is sufficient, which Schneier seems to

side discussion wonders whether bruce may be a bit on the
pollyanna side on this aspect.

randy

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Sep 2013 21:30:18 -0800

> pollyanna side on this aspect.

That's a really interesting question, and I have no idea what
the answer is.  One reason it's interesting is that until
this all broke there was a reasonable assumption that as long
as you were more inconvenient to compromise than your neighbors,
you were safe.  That actually appears not to be the case at all
where eavesdropping is concerned.

Melinda

---

From: Jari Arkko <[email-masked]>
Date: Fri, 6 Sep 2013 09:04:41 +0300

I think we should seize this opportunity to take a hard look at what we can do better. Yes, it is completely correct that this is only partially a technical problem, and that there is a lot of technology that, if used, would help. And that technical issues outside IETF space, like endpoint security, or the properties of specific products or implements affects the end result in major ways. And that no amount of communication security helps you if you do not the guy at the other end.

But it is also obvious to me that we do not have a situation where everything that could be done has been done. I think we can do more. Some examples:

* we're having a discussion in http 2.0 work whether encryption should be mandatory
* the perpass list has talked about understanding better where fingerprinting is an issue with IETF protocols
* maybe it would be time to start having specs say that implementations must refuse older, weak algorithms
* we could do more analysis and review to understand where the weak points and development opportunities are -- too early to say there are none

And please do not think about all this just in terms of the recent revelations. The security in the Internet is still a challenge, and if there are improvements they will be generally useful for many reasons and for many years to come. Perhaps this year's discussions are our ticket to motivate the world to move from "by default insecure" communications to "by default secure". Publicity and motivation are important, too.

So I for one would like to see work to determine what we could do, and some meeting time in the Vancouver agenda to talk about it.

Jari

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Sep 2013 08:07:01 +0200

> Certificate Transparency and have a pretty good start on a PRISM Proof

Not when the keys reside with a service that can be coerced.

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Fri, 6 Sep 2013 09:07:07 +0300

> And that no amount of communication security helps you if you do not the guy at the other end.

Do not *trust* the guy at the other end. Typos, sigh…

---

From: SM <[email-masked]>
Date: Thu, 05 Sep 2013 23:46:18 -0700

>"feel-good" measure without real impact.

:-)

>Second, technology can never fix what is essentially a political 
>problem. for eg. We mandate strong security protocols and end-to-end 
>encryption in HTTP(S) by default. Lets

In a Last Call comment a few months ago it was mentioned that a 
specification takes the stance that security is an optional 
feature.  I once watched a Security Area Director spend thirty 
minutes trying to explain to a working group that security feature 
should be implemented.  If I recall correctly the working group was 
unconvinced.

Would the community raise it as an issue during a Last Call if a 
proposed protocol did not have strong security features?  It's up to 
the reader to determine the answer to that.

>  assume all browsers implement this and do this perfectly without 
> software flaws. All the NSA has to do is to compromise the other 
> endpoint (controlled by ACME major corp). ACME gives over the 

Yes.

>  what are we going to do. The IETF can make an political statement 
> by taking a stand but that may mean nothing in reality when the 
> laws are weak. Another example is when you have

Taking a stand that means nothing is a feel-good measure.

>  encrypted your drive and do not want to hand over the keys as it 
> has some personal (and possibly incriminating evidence). In several 
> countries you can be held in jail indefinitely (with obvious 
> renewals of sentences) until you hand the keys over[1]. So in 
> summary, technology cannot solve political and legal issues. At 
> best it can make it harder. But in this case maybe not even that.

The IETF outlook does not apply in several countries.  The IETF does 
not seem to pay much attention to that details (re. hand the 
keys).  It's not clear what the emergency is.  Phillip Hallam-Baker 
and Brian Carpenter already mentioned that it's not like this is a surprise.

According to a news article key architects of the Internet plan to 
fight back by drawing a plan to defend against state-sponsored 
surveillance.  Anyway, if someone really wanted to call for an 
emergency response the person would have sent it to an IETF mailing list.

At 20:08 05-09-2013, Ted Lemon wrote:
>I think we all knew NSA was collecting the data.   Why didn't we do 
>something about it sooner?   Wasn't it an emergency when the PATRIOT 
>act was passed?   We certainly thought it was an emergency back in 
>the days of Skipjack, but then they convinced us we'd won.   Turns 
>out they just went around us.

I would describe it as a scuffle instead of a battle.  My guess is 
that the IETF did not do anything sooner as nobody knows what to do, 
or it may be that the IETF has become conservative and it does not 
pay attention to the minority report.

At 23:04 05-09-2013, Jari Arkko wrote:
>I think we should seize this opportunity to take a hard look at what 
>we can do better.

:-)

>And please do not think about all this just in terms of the recent 
>revelations. The

That's an interesting perspective.

>  security in the Internet is still a challenge, and if there are 
> improvements they will be generally useful for many reasons and for 
> many years to come. Perhaps this year's discussions are our ticket 
> to motivate the world to move from "by default insecure" 
> communications to "by default secure". Publicity and motivation are 
> important, too.

Yes.

Regards,
-sm

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 6 Sep 2013 09:25:39 +0200

> * we're having a discussion in http 2.0 work whether encryption should be mandatory

Given the relative impact of http I think that this is the most important
of your suggestions. Frankly, I do not think it is sensible to block
mandatory crypto in http 2.0. 

However, I think it is also important to look at how we handle the
key distribution problem. The traditional X.509 model has repeatedly
been shown to be extremely vulnerable to bad management and directed
attacks. Further, the dependency on relatively few root CA instances
and the lack of domain name scope limitations makes an attack on said
CA not only likely but also most rewarding to the attacker.

I do think that more distributed technoligies like DANE play an important
rôle here.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Like I always say -- nothing can beat the BRATWURST here in DUSSELDORF!!

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Sep 2013 10:26:18 +0300

Bruce might not know that we have already various activities ongoing. I 
just recently produced a short writeup about the efforts related to this 
topic ongoing at the last IETF meeting on my blog:
http://www.tschofenig.priv.at/wp/?p=993

Ciao
Hannes

---

From: Adam Novak <[email-masked]>
Date: Fri, 06 Sep 2013 00:47:22 -0700

> I don't intend that to be a rhetorical question.

One way to frustrate this sort of dragnet surveillance would be to 
reduce centralization in the Internet's architecture. Right now, the way 
the Internet works in practice for private individuals, all your traffic 
goes up one pipe to your ISP. It's trivial to tap, since the tapping can 
be centralized at the ISP end.

The IETF focused on developing protocols (and reserving the necessary 
network numbers) to facilitate direct network peering between private 
individuals, it could make it much more expensive to mount large-scale 
traffic interception attacks.

---

From: t.p. <[email-masked]>
Date: Fri, 6 Sep 2013 08:54:50 +0100

----- Original Message -----
From: "Phillip Hallam-Baker" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>
Cc: "IETF Discussion Mailing List" <[email-masked]>
Sent: Friday, September 06, 2013 4:56 AM
> encrypted is sent encrypted.

That sounds like the 'End User Fallacy number one' that I encounter all
the time in my work.  If only everything were encrypted, then we would
be completely safe.  Well, no (as you Phillip know well).  It depends on
the strength of the ciphers (you can get a little padlock on your screen
with SSL 2 which was the default in my local public access system until
recently).  It depends on the keys being secret (one enterprise system I
was enrolled on in 2003 will not let me change my password, ever - only
the system administrator has that power).  It depends on authentication
(I have a totally secure channel, unbreakable in the next 50 years, but
it is not to my bank but to a Far Eastern Power).  And so on.  Yet every
few weeks I hear the media saying, 'look for the padlock'.

I think that the obvious step to improving security is to get the world
at large possessing and using certificates, in the same way as the
governments of the world, not very long agao, persuaded us to use
passports.

Tom Petch

---

From: Vinayak Hegde <[email-masked]>
Date: Fri, 6 Sep 2013 13:43:01 +0530

On Fri, Sep 6, 2013 at 12:16 PM, SM <[email-masked]> wrote:

> specification takes the stance that security is an optional feature.  I
> once watched a Security Area Director spend thirty minutes trying to
> explain to a working group that security feature should be implemented.  If
> I recall correctly the working group was unconvinced.
>
> Would the community raise it as an issue during a Last Call if a proposed
> protocol did not have strong security features?  It's up to the reader to
> determine the answer to that.

It is tragic if the community does understand strong encryption is
essential in many cases (with the caveat that it is not a panacea for all
security breaches) As for raising issues at the last-call. Why not ? The
last-call is no different than any other mailing list discussion or going
to the mic in a physical meeting. (Other than the urgency of having the
last chance to comment ?)

-- Vinayak

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Sep 2013 11:36:02 +0300

> I'm not saying there's no issue or no work to do, but what's new about

Still at the end of last year I remember conversations in working groups 
that questions why we need TLS security for protocols like SCIM (a 
protocol that shuffles credentials around).

I don't think that the decision in the RTCWeb group against SDES would 
have been possible without the NSA news.

I also remember the Internet Privacy workshop the IAB and others 
organized about 2 years ago and back then we argued whether government 
surveillance is something we should focus on or whether we are mainly 
interested in companies who impact your privacy.

While some (many) have already anticipated that the NSA (and other 
governments) deploy massive surveillance technologies the extend to 
which it is done has surprised most security persons I know.

In a nutshell, the understanding and awareness of the wider Internet 
community has changed with those news.

Ciao
Hannes

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 06 Sep 2013 11:30:54 +0100

> to what's already done or in the works.

There is a whole bunch of stuff we can do to make transit traffic less 
observable.

In other words we can modify things so the only think you know about a 
packet is where it is going, not what it is or who it came from.

Stewart

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Sep 2013 11:51:19 +0100

Summarising a *lot* :-)

On 09/06/2013 11:30 AM, Stewart Bryant wrote:
> 
> There is a whole bunch of stuff we can do

I fully agree. Some more detail on one of those...

We setup the perpass list [1] as a venue for triaging
specific proposals in this space. A few weeks in, we
have one I-D [2] (very much a -00) that tries to describe
a threat model that matches the recent revelations,
and that could be a good reference when folks are
developing protocols.

We have found volunteers to write a draft for a BCP
on how to use perfect forward secrecy in TLS, more
common use of which (we still think) would mitigate a
bunch of the ways in which TLS traffic could be
subverted, given various forms of collusion/coercion.
I hope the -00 for that will pop out in a weekish.

We've had some discussion about how to do better with
email, but that's not yet landed on specifics that
could be taken further. And a couple of other topics
have come up. More are welcome.

For any such topic that looks like it'll turn into
something actionable (in the IETF context), I'm very
happy to push to get it adopted by a relevant WG or
to get it AD sponsored.

If you care about this stuff, then get on that list
and make concrete proposals and write I-Ds about ways
the IETF can improve the situation. If the content
is good, you'll find you're pushing on an open door
(at least as far as the SEC ADs are concerned:-).

And as we all know the IETF cannot "solve the problem"
here, but as Stewart rightly said: there is stuff we
can do better. So let's do it.

I do think some kind of session in Vancouver would be
useful to move this along some more and there's
discussion ongoing within the IESG and IAB on how to
best do that. If we (IESG/IAB) fail in that, please do
beat us up mightily at the mic in Vancouver.

Cheers,
S.

[1] https://www.ietf.org/mailman/listinfo/perpass
[2] http://tools.ietf.org/html/draft-trammell-perpass-ppa

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Sep 2013 15:07:28 +0300

> Tell me what the IETF could be doing that it isn't already doing.
It really depends where you see the boundaries of the IETF.

For some the IETF only produces documents and that's it. Clearly, we 
have a lot of specification work ongoing in different areas that helps 
to mitigate various security vulnerabilities. This ranges from recent 
work on XMPP end-to-end security (as in 
http://tools.ietf.org/html/draft-miller-3923bis-02) all the way to the 
recent RTCWEB discussions on using DTLS-SRTP as a key management protocol.

For other folks the IETF does much more, such as to reach out to those 
deploying our technology. Many folks involved in the IETF community 
produce open source code, write article in popular computer magazines 
explaining how to use the technology, give presentations at various 
conferences, teach at universities and research institutes, provide 
consulting, etc. The list is long.

It is obviously easier to write (security) documents but somewhat more 
complex to get them widely deployed. Example: TLS everywhere, DNSSEC, 
email security, routing security, etc.

While we are able to fill gaps in security protocols fairly quickly we 
don't always seem to make the right choices because the interests of 
various participants are not necessarily aligned. In general, we seem to 
develop an insecure version and a secure version of a protocol. 
Unfortunately, the insecure version gets widely deployed and we have an 
incredible hard time to introduce the secure version.

In addition to the specification work we could think about how to reach 
out to the broader Internet ecosystem a bit better. Since we have lots 
of folks in the IETF I don't think it is an impossible task but it might 
require a bit of coordination. Right now would be a good time to launch 
some of those initiatives since most people currently understand the 
need for security.

Ciao
Hannes

---

From: Jorge Amodio <[email-masked]>
Date: Fri, 6 Sep 2013 07:51:05 -0500

IMHO. There is no amount of engineering that can fix stupid people doing
stupid things... on both sides of the stupid line.

-J

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 06 Sep 2013 06:59:18 -0600

On 9/6/13 1:47 AM, Adam Novak wrote:
>> shouldn't be doing. I care about all those things, but the
>> question here is what standards or informational outputs from the
>> IETF are needed, in addition to what's already done or in the
>> works.
>> 
> reduce centralization in the Internet's architecture. Right now,
> the way the Internet works in practice for private individuals, all
> your traffic goes up one pipe to your ISP. It's trivial to tap,
> since the tapping can be centralized at the ISP end.
> 
> The IETF focused on developing protocols (and reserving the
> necessary network numbers) to facilitate direct network peering
> between private individuals, it could make it much more expensive
> to mount large-scale traffic interception attacks.

+1. There's already work on things like MANET, but this seems a useful
avenue of work.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alan Johnston <[email-masked]>
Date: Fri, 6 Sep 2013 08:02:15 -0500

On Fri, Sep 6, 2013 at 7:07 AM, Hannes Tschofenig <[email-masked]
> wrote:

> For some the IETF only produces documents and that's it. Clearly, we have
> a lot of specification work ongoing in different areas that helps to
> mitigate various security vulnerabilities. This ranges from recent work on
> XMPP end-to-end security (as in http://tools.ietf.org/html/**
> draft-miller-3923bis-02<http://tools.ietf.org/html/draft-miller-3923bis-02>)
> all the way to the recent RTCWEB discussions on using DTLS-SRTP as a key
> management protocol.
>

If we took protection against MitM attacks seriously, we would be using
ZRTP for RTCWEB instead of DTLS-SRTP.  See

     http://tools.ietf.org/html/draft-johnston-rtcweb-zrtp

- Alan -

---

From: Martin Sustrik <[email-masked]>
Date: Fri, 06 Sep 2013 15:04:02 +0200

On 06/09/13 14:07, Hannes Tschofenig wrote:

> various participants are not necessarily aligned.

So, what if an NSA guys comes in and proposes backdoor to be added to a 
protocol? Is it even a valid interest? Does IETF as an organisation have 
anything to say about that or does it remain strictly neutral?

Martin

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Sep 2013 15:07:15 +0200

On 9/6/13 3:04 PM, Martin Sustrik wrote:
> So, what if an NSA guys comes in and proposes backdoor to be added to
> a protocol? Is it even a valid interest? Does IETF as an organisation
> have anything to say about that or does it remain strictly neutral?
>
It's happened before and we as a community have said no.  See RFC 2804.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 6 Sep 2013 06:20:48 -0700

On 9/6/13 12:54 AM, t.p. wrote:
>> The design I think is practical is to eliminate all UI issues by 
>> insisting that encryption and decryption are transparent. Any email 
>> that can be sent encrypted is sent encrypted.
>
> That sounds like the 'End User Fallacy number one' that I encounter 
> all the time in my work. If only everything were encrypted, then we 
> would be completely safe.

Actually, I disagree that this fallacy is at play here. I think we need 
to separate the concept of end-to-end encryption from authentication 
when it comes to UI transparency. We design UIs now where we get in the 
user's face about doing encryption if we cannot authenticate the other 
side and we need to get over that. In email, we insist that you 
authenticate the recipient's certificate before we allow you to install 
it and to start encrypting, and prefer to send things in the clear until 
that is done. That's silly and is based on the assumption that 
encryption isn't worth doing *until* we know it's going to be done 
completely safely. We need to separate the trust and guarantees of 
safeness (which require *later* out-of-band verification) from the whole 
endeavor of getting encryption used in the first place.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Scott Brim <[email-masked]>
Date: Fri, 6 Sep 2013 09:45:26 -0400

I wouldn't focus on government surveillance per se.  The IETF should
consider that breaking privacy is much easier than it used to be,
particularly given consolidation of services at all layers, and take
that into account in our engineering best practices.  Our mission is
to make the Internet better, and right now the Internet's weakness in
privacy is far from "better".  The mandatory security considerations
section should become security and privacy considerations.  The
privacy RFC should be expanded and worded more strongly than just nice
suggestions.  Perhaps the Nomcom should ask candidates about their
understanding of privacy considerations.

Scott

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 06 Sep 2013 16:00:24 +0200

>Tell me what the IETF could be doing that it isn't already doing.

The United States justify these programs saying they are primarily used
to support their various current and future war efforts. Not meeting at
any level in countries currently at war might be a sound IETF policy.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Sep 2013 10:02:19 -0400

--On Friday, September 06, 2013 06:20 -0700 Pete Resnick
<[email-masked]> wrote:

> Actually, I disagree that this fallacy is at play here. I
> think we need to separate the concept of end-to-end encryption
> from authentication when it comes to UI transparency. We
> design UIs now where we get in the user's face about doing
> encryption if we cannot authenticate the other side and we
> need to get over that. In email, we insist that you
> authenticate the recipient's certificate before we allow you
> to install it and to start encrypting, and prefer to send
> things in the clear until that is done. That's silly and is
> based on the assumption that encryption isn't worth doing
> *until* we know it's going to be done completely safely. We
> need to separate the trust and guarantees of safeness (which
> require *later* out-of-band verification) from the whole

Pete,

At one level, I completely agree.  At another, it depends on the
threat model.  If the presumed attacker is skilled and has
access to packets in transit then it is necessary to assume that
safeguards against MITM attacks are well within that attacker's
resource set.  If those conditions are met, then encrypting on
the basis of a a key or certificate that can't be authenticated
is delusional protection against that threat.  It may still be
good protection against more casual attacks, but we do the users
the same disservice by telling them that their transmissions are
secure under those circumstances that we do by telling them that
their data are secure when they see a little lock in their web
browsers.

Certainly "encrypt first, authenticate later" is reasonable if
one doesn't send anything sensitive until authentication has
been established, but it seems to me that would require a rather
significant redesign of how people do things, not just how
protocols work.

best,
   john

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 6 Sep 2013 10:08:24 -0400

One thing that would be helpful is to encourage the use of
Diffie-Hellman everywhere.  Even without certificates that can be
trusted, we can eliminate the ability of casual, dragnet-style
surveillance.  Sure, an attacker can still do a MITM attack.  But (a)
people who are more clueful can do certificate pinning/verification,
and (b) if the NSA is really putting data taps into tier 1 providers'
high speed interconnects, they can only carry out MITM attacks on a
bulk scale by placing racks and racks of servers, which will require
significant amounts of cooling and power, in places that are much more
likely where they would be noticed.  It's no longer a data tap hidden
away somewhere in a closet near a tier 1's NAP.

For too long, I think, we've let the perfect be the enemy of the good.
Using TLS with DH to secure SMTP connections is valuable even if it is
subject to MITM attacks, and even if the NSA/FBI can hand a National
Security Letter to the cloud provider.  At least this way they will be
forced to go the NSL route (and it will show up in whatever
transparency reports that Google or Microsoft or Facebook are allowed
to show to the public), or spend $$$ on huge racks of servers in
public data centers, which maybe means less money to subvert standards
setting activities.

Although perfect security is ideal, increasing the cost of casual
style dragnet surveillance is still a Good Thing.

						- Ted

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 6 Sep 2013 10:16:12 -0400

On Fri, Sep 06, 2013 at 06:20:48AM -0700, Pete Resnick wrote:
> 
> In email,
> we insist that you authenticate the recipient's certificate before
> we allow you to install it and to start encrypting, and prefer to
> send things in the clear until that is done. That's silly and is
> based on the assumption that encryption isn't worth doing *until* we
> know it's going to be done completely safely.

Speaking of which, Jim Gettys was trying to tell me yesterday that
BIND refuses to do DNSSEC lookups until the endpoint client has
generated a certificate.  Which is bad, since out-of-box, a home
router doesn't have much in the way of entropy at that point, so you
shouldn't be trying to generate certificates at the time of the first
boot-up, but rather to delay until you've had enough of a chance to
gather some entropy.  (Or put in a real hardware RNG, but a
race-to-the-bottom in terms of BOM costs makes that not realistic.)  I
told him that sounds insane, since you shouldn't need a
certificate/private key in order to do digital signature verification.

Can someone please tell me that BIND isn't being this stupid?

					- Ted

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Sep 2013 15:26:42 +0100

Theodore Ts'o <[email-masked]> wrote:

> generated a certificate.

That is wrong. DNSSEC validation affects a whole view - i.e. it is
effectively global.

Clients can request DNSSEC records or not, regardless of whether they do
any transaction security. Clients can do DNSSEC validation without any
private keys.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 6 Sep 2013 10:29:11 -0400

> any transaction security. Clients can do DNSSEC validation without any

That's what I hoped, thanks.

						- Ted

---

From: Stefan Winter <[email-masked]>
Date: Fri, 06 Sep 2013 16:31:03 +0200

+1. I'd +10 if I could :-)

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Pete Resnick <[email-masked]>
Date: Fri, 6 Sep 2013 07:38:00 -0700

On 9/6/13 7:02 AM, John C Klensin wrote:
> ...It may still be

Actually, I think the latter is really what I'm suggesting. We've got do 
the encryption (for both the minimal protection from passive attacks as 
well as setting things up for doing good security later), but we've also 
got to design UIs that not only make it easier for users to deal with 
encrpytion, but change the way people think about it.

(Back when we were working on Eudora, we got user support complaints 
that "people can read my email without typing my password". What they in 
fact meant was that if you started the application, it would normally 
ask for your POP password in order to check mail, but you could always 
click "Cancel" and read the mail that had been previously downloaded. 
Users presumed that since they were being prompted for the password when 
the program launched -- just like what used to happen when they "logged 
in" to read mail on their Unix/etc. accounts -- the password was 
protecting the local data, not that it was only being used to 
authenticate to the server to download mail. You'd ask them why they 
weren't so worried about people reading their Microsoft Word files and 
they'd give you dumb looks. Sometimes you do have to redesign "how 
people do things".)

pr

---

From: Joe Abley <[email-masked]>
Date: Fri, 6 Sep 2013 10:43:42 -0400

> BIND refuses to do DNSSEC lookups until the endpoint client has

All modern DNSSEC-capable resolvers (regardless of whether validation has been turned on) will set DO=1 in the EDNS0 header and will retrieve signatures in responses if they are available. BIND9 is not a counter-example. Regardless, an end host downstream of a resolver that behaves differently (but that is capable of and desires to perform its own validation) can detect an inability to receive signatures, and can act accordingly.

There is no client certificate component of DNSSEC. The trust anchor for the system is published as part of root zone processes at IANA, and a variety of mechanisms are available to infer trust in a retrieved trust anchor. (These could use more work, but they exist.)

There is a (somewhat poorly-characterised and insufficiently-measured) interaction with a variety of middleware in firewalls, captive hotel hotspot, etc that will prevent an end host from being able to validate responses from the DNS, but in those cases the inability to validate is known by the end host; you still have the option of closing your laptop and reattaching it to the network somewhere else.

>  Which is bad, since out-of-box, a home
> gather some entropy.

In DNSSEC, signatures are generated before publication of zone data, and are verified by validators. You don't need a high-quality entropy source to validate a signature. There is no DNSSEC requirement for entropy in a home router or an end host.

>  (Or put in a real hardware RNG, but a

I think you were on the right track, there.

> Can someone please tell me that BIND isn't being this stupid?

This thread has mainly been about privacy and confidentiality. There is nothing in DNSSEC that offers either of those, directly (although it's an enabler through approaches like DANE to provide a framework for secure distribution of certificates). If every zone was signed and if every response was validated, it would still be possible to tap queries and tell who was asking for what name, and what response was returned.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Sep 2013 07:55:44 -0700

> stupid things... on both sides of the stupid line.

Correct.  Within the IETF, the most serious example of stupidity is any 
line of analysis that considers end-users to be stupid or lazy, rather 
than treating them as system components with various pragmatic 
constraints, just like any other system component.

So the real challenge is for us to be clear about the pragmatics when we 
talk about end-users.  Here the real problem is that the pragmatics are 
only superficially understood, even by the usability (HCI, UXD, UCE, 
UCD...) experts.

That points to a second serious challenge, namely that we can't know 
very well what will work for end-users and what won't.

The model that I've described for some years is that the best user 
design cognitive processing models -- processing limits, memory limits, 
attention limits, etc. -- about end-users suggest reasonable theories 
for /starting/ designs, but never ensure good /final/ designs.  That 
requires testing.

At this summer's SOUPS conference I floated this summary past a variety 
of senior Usable Security folks during one of the sessions and folks 
generally nodded in agreement.

In other words, the IETF needs to assume that we don't know what will 
work for end users and we need to therefore focus more on processing by 
end /systems/ rather than end /users/.

We also need to avoid the 'then a miracle happens' faith that end system 
designers will magically figure out the best user interface design for 
security, since they have failed at that for the last 25 years; they'll 
eventually succeed but they haven't, so far.

d/

---

From: Scott Brim <[email-masked]>
Date: Fri, 6 Sep 2013 11:12:17 -0400

On Fri, Sep 6, 2013 at 10:55 AM, Dave Crocker <[email-masked]> wrote:
> In other words, the IETF needs to assume that we don't know what will work
> for end users and we need to therefore focus more on processing by end
> /systems/ rather than end /users/.

... and do not close off any options because we assume people won't
want to use them.

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Sep 2013 11:23:04 -0400

--On Friday, September 06, 2013 07:38 -0700 Pete Resnick
<[email-masked]> wrote:

> Actually, I think the latter is really what I'm suggesting.
> We've got do the encryption (for both the minimal protection
> from passive attacks as well as setting things up for doing
> good security later), but we've also got to design UIs that
> not only make it easier for users to deal with encrpytion, but
> change the way people think about it.
> 
> (Back when we were working on Eudora, we got user support
> complaints that "people can read my email without typing my
> password". What they in fact meant was that if you started the
> application, it would normally ask for your POP password in
>...

Indeed.  And I think that one of the more important things we
can do is to rethink UIs to give casual users more information
about what it going on and to enable them to take intelligent
action on decisions that should be under their control.  There
are good reasons why the IETF has generally stayed out of the UI
area but, for the security and privacy areas discussed in this
thread, there may be no practical way to design protocols that
solve real problems without starting from what information a UI
needs to inform the user and what actions the user should be
able to take and then working backwards.  As I think you know,
one of my personal peeves is the range of unsatisfactory
conditions --from an older version of certificate format or
minor error to a verified revoked certificate -- that can
produce a message that essentially says "continuing may cause
unspeakable evil to happen to you" with an "ok" button (and only
an "ok" button).  

Similarly, even if users can figure out which CAs to trust and
which ones not (another issue and one where protocol work to
standardize distribution of CA reputation information might be
appropriate) editing CA lists whose main admission qualification
today seems to be cosy relationships with vendors (and maybe the
US Govt) to remove untrusted ones and add trusted ones requires
rocket scientist-level skills.  If we were serous, it wouldn't
be that way.  

And the fact that those are 75% of more UI issues is probably no
longer an excuse.

    john

---

From: Brian Trammell <[email-masked]>
Date: Fri, 6 Sep 2013 17:23:09 +0200

hi Scott, all,

On Sep 6, 2013, at 3:45 PM, Scott Brim <[email-masked]> wrote:

> privacy is far from "better".

Indeed, pervasive surveillance is merely a special case of eavesdropping as a privacy threat, with the important difference that eavesdropping (as discussed in RFC 6973) explicitly has an target in mind, while pervasive surveillance explicitly doesn't. So what we do to improve privacy will naturally make surveillance harder, in most cases; I hope that draft-trammell-perpass-ppa will evolve to fill in the gaps.

> The mandatory security considerations

Having read RFC 6973 in detail while working on that draft, I'd say it's a very good starting point, and indeed even consider it required reading. We can certainly take its guidance to heart as if it were more strongly worded than it is. :)

Cheers,

Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 11:32:14 -0400

On Sep 6, 2013, at 2:46 AM, SM <[email-masked]> wrote:
> I would describe it as a scuffle instead of a battle.  My guess is that the IETF did not do anything sooner as nobody knows what to do, or it may be that the IETF has become conservative and it does not pay attention to the minority report.

It was definitely a battle.   There were threats of imprisonment, massive propaganda dumps (think of the children!), etc.   People broke the law, moved countries, etc.   We just forget it because "we" "won" it, and it seems smaller in memory than it was when it was happening.

The IETF didn't do anything because the tin foil hat contingent didn't have consensus, and we had no data to force the point.   As you alluded to earlier, it's historically been very difficult to get people to treat security and privacy seriously, and frankly it still is.

So this isn't an emergency.   It's a teachable moment.   We should pay attention.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 6 Sep 2013 08:41:17 -0700

On 9/6/13 8:23 AM, John C Klensin wrote:

> I think that one of the more important things we
> able to take and then working backwards.
> [...]

Absolutely. There is clearly a good motivation: A particular UI choice 
should not *constrain* a protocol, so it is essential that we make sure 
that the protocol is not *dependent* on the UI. But that doesn't mean 
that UI issues should not *inform* protocol design. If we design a 
protocol such that it makes assumptions about what the UI will be able 
to provide without verifying those assumptions are realistic, we're in 
serious trouble. I think we've done that quite a bit in the 
security/application protocol space.

> unspeakable evil to happen to you" with an "ok" button (and only

OK, one last nostalgic anecdote about Eudora before I go back to 
finishing my spfbis Last Call writeup:

MacTCP (the TCP/IP stack for the original MacOS) required a handler 
routine for ICMP messages for some dumb reason; you couldn't just set it 
to null in your code. So Steve implemented one. Whenever an ICMP message 
came in for a current connection (e.g., Destination Unreachable), Eudora 
would put up a dialog box. It read "Eudora has received an ICMP 
Destination Unreachable message." The box had a single button. It read, 
"So What?"

Working for Steve was a hoot.

pr

---

From: Scott Brim <[email-masked]>
Date: Fri, 6 Sep 2013 11:43:24 -0400

On Fri, Sep 6, 2013 at 11:41 AM, Pete Resnick <[email-masked]> wrote:
> OK, one last nostalgic anecdote about Eudora before I go back to finishing
> my spfbis Last Call writeup:
>
> MacTCP (the TCP/IP stack for the original MacOS) required a handler routine
> for ICMP messages for some dumb reason; you couldn't just set it to null in
> your code. So Steve implemented one. Whenever an ICMP message came in for a
> current connection (e.g., Destination Unreachable), Eudora would put up a
> dialog box. It read "Eudora has received an ICMP Destination Unreachable
> message." The box had a single button. It read, "So What?"
>

(like)

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Sep 2013 11:45:48 -0400

--On Friday, September 06, 2013 10:43 -0400 Joe Abley
<[email-masked]> wrote:

> This thread has mainly been about privacy and confidentiality.
> There is nothing in DNSSEC that offers either of those,
> directly (although it's an enabler through approaches like
> DANE to provide a framework for secure distribution of
> certificates). If every zone was signed and if every response
> was validated, it would still be possible to tap queries and
> tell who was asking for what name, and what response was
> returned.

Please correct me if I'm wrong, but it seems to me that
DANE-like approaches are significantly better than traditional
PKI ones only to the extent to which:

	- The entities needing or generating the certificates
	are significantly more in control of the associated DNS
	infrastructure than entities using conventional CAs are
	in control of those CAs.
	
	- For domains that are managed by registrars or other
	third parties (I gather a very large fraction of them at
	the second level), whether one believes those registrars
	or other operators have significantly more integrity and
	are harder to compromise than traditional third party CA
	operators.

best,
   john

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 11:46:17 -0400

> I do think that more distributed technoligies like DANE play an important

Right, because there's no way the NSA could ever pwn the DNS root key.

What we should probably be thinking about here is:

  - Mitigating single points of failure (IOW, we _cannot_ rely
    on just the root key)
  - Hybrid solutions (more trust sources means more work to
    compromise)
  - Sanity checking (if a key changes unexpectedly, we should
    be able to notice)
  - Multiple trust anchors (for stuff that really matters, we
    can't rely on the root or on a third party CA)
  - Trust anchor establishment for sensitive communications
    (e.g. with banks)

The threat model isn't really the NSA per se—if they really want to bug you, they will, and you can't stop them, and that's not a uniformly bad thing.   The problem is the breathtakingly irresponsible weakening of crypto systems that has been alleged here, and what we can do to mitigate that.   Even if we aren't sure that it's happened, or precisely what's happened, it's likely that it has happened, or will happen in the near future.  We should be thinking in those terms, not crossing our fingers and hoping for the best.

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Sep 2013 11:59:19 -0400

--On Friday, September 06, 2013 08:41 -0700 Pete Resnick
<[email-masked]> wrote:

>...
> Absolutely. There is clearly a good motivation: A particular
> UI choice should not *constrain* a protocol, so it is
> essential that we make sure that the protocol is not
> *dependent* on the UI. But that doesn't mean that UI issues
> should not *inform* protocol design. If we design a protocol
> such that it makes assumptions about what the UI will be able
> to provide without verifying those assumptions are realistic,
> we're in serious trouble. I think we've done that quite a bit
> in the security/application protocol space.

Yes.  It also has another implication that goes to Dave's point
about how the IETF should interact with UI designers.   In my
youth I worked with some very good early generation HCI/ UI
design folks.  Their main and most consistent message was that,
from a UI functionality standpoint, the single most important
consideration for a protocol, API, or similar interface was to
be sure that one had done a thorough analysis of the possible
error and failure conditions and that sufficient information
about those conditions could get to the outside to permit the UI
to report things and take action in an appropriate way.    From
that point of view, any flavor of a "you lose" -> "ok" message,
including blue screens and "I got irritated and disconnected
you"  is a symptom of bad design and much more commonly bad
design in the protocols and interfaces than in the UI.  

Leaving the UI designs to the UI designers is fine but, if we
don't give them the tools and information they need, most of the
inevitable problems are ours.

> OK, one last nostalgic anecdote about Eudora before I go back
> to finishing my spfbis Last Call writeup:
>...

I can only imagine, but the story is not a great surprise.

   john

---

From: SM <[email-masked]>
Date: Fri, 06 Sep 2013 08:53:21 -0700

Hi Vinayak,
At 01:13 06-09-2013, Vinayak Hegde wrote:
>essential in many cases (with the caveat that it is not a panacea 
>for all security breaches) As for raising issues at the last-call. 
>Why not ? The last-call is no different than any other mailing list 
>discussion or going to the mic in a physical meeting. (Other than 
>the urgency of having the last chance to comment ?)

The Last Call is different from going to the microphone in a physical 
meeting.  Fancy speeches at the microphone are impressive.  It takes 
more work to identify issues and explain why it is or can be a 
problem.  Martin Sustrik asked:

At 06:04 06-09-2013, Martin Sustrik wrote:
>So, what if an NSA guys comes in and proposes backdoor to be added 
>to a protocol? Is it even a valid interest? Does IETF as an 
>organisation have anything to say about that or does it remain 
>strictly neutral?

Would anyone notice it on a Last Call?  Would anyone say something 
about it?  I doubt that.  Ted Lemon said it nicely: "we should pay attention".

Regards,
-sm

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 06 Sep 2013 11:10:11 -0500

On 9/6/2013 10:46 AM, Ted Lemon wrote:
> The threat model isn't really the NSA per se—if they really want to 
> bug you, they will, and you can't stop them, and that's not a 
> uniformly bad thing. The problem is the breathtakingly irresponsible 
> weakening of crypto systems that has been alleged here, and what we 
> can do to mitigate that. Even if we aren't sure that it's happened, or 
> precisely what's happened, it's likely that it has happened, or will 
> happen in the near future. We should be thinking in those terms, not 
> crossing our fingers and hoping for the best. 

IIUC, I'm with Ted.

We should be thinking in those terms, and thinking broadly.

I have to wonder whether weakening crypto systems to allow pervasive 
passive monitoring by "national agencies" would weaken them enough for 
technologically savvy corporations to monitor their competitors, for 
instance.

Spencer

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Sep 2013 17:11:55 +0100

> 	are harder to compromise than traditional third party CA

Yes, but there are some compensating pluses:

You can get a meaningful improvement to your security by good choice of
registrar (and registry if you have flexibility in your choice of name).
Other weak registries and registrars don't reduce your DNSSEC security,
whereas PKIX is only as secure as the weakest CA.

DNSSEC has tricky timing requirements for key rollovers. This makes it
hard to steal a domain without causing validation failures.

An attacker can use a compromise of your DNS infrastructure to get a
certificate from a conventional CA, just as much as they could compromise
DNSSEC-based service authentication.

Tony.

---

From: Arturo Servin <[email-masked]>
Date: Fri, 06 Sep 2013 13:16:25 -0300

On 9/6/13 4:47 AM, Adam Novak wrote:
> reduce centralization in the Internet's architecture. Right now, the
> way the Internet works in practice for private individuals, all your
> traffic goes up one pipe to your ISP. It's trivial to tap, since the
> tapping can be centralized at the ISP end.
    And all our security is based in single points that are easy to abuse.

/as

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Sep 2013 19:48:14 +0300

On 06.09.2013 18:53, SM wrote:
> Would anyone notice it on a Last Call?  Would anyone say something about
> it?  I doubt that.  Ted Lemon said it nicely: "we should pay attention".

You will have to interpret what a backdoor in a protocol would be.
I guess that would be a weaker security feature, delaying work or
starting some other work that plays in their favor.

That would, however, be a bit tricky.

In some sense this is not really needed by them since we have lots of 
companies who already argue for weaker security properties, for a 
variety of different reasons.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 6 Sep 2013 18:54:45 +0200

> to what's already done or in the works.

I think we need to rethink the way we do protocols or the way security
WGs do standards. It will be easy to blame/ask the Security Area
participants/experts of what was not done or what should been done,
however, this area seems more as a cross-area, and I suggest that the
IETF re-thinks or re-structures the Security area and/or its WGs'
Charteres.

AB

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Sep 2013 13:25:47 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> act was passed?  We certainly thought it was an emergency back in the
    >> days of Skipjack, but then they convinced us we'd won.  Turns out they
    >> just went around us.

    > Tell me what the IETF could be doing that it isn't already doing.

1) We could be telling the public about the protocols that we designed 10, 15,
   and even 20 years ago. Some of which even have rather widespread
   implementation, but seem to have zero use.
   (S/MIME is in every copy of Outlook and Thunderbird, AFAIK)

What would the spam situation be like if 90% of emails were regularly
signed back in 1999?  Yes, and DKIM can sign message bodies now too.
We should be telling people about it.

2) Use this stuff ourselves!!!!

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Dean Willis <[email-masked]>
Date: Fri, 6 Sep 2013 13:31:10 -0500

> It's happened before and we as a community have said no.  See RFC 2804.

What if they didn't say they were NSA guys, but just discretely worked a weakness into a protocol? What if they were a trusted senior member of the community?

That way lies madness -- but it is a madness we must contemplate. Broader REAL consensus, rather than apathetic agreement with a single contributor's assertions is probably the right way to go.

That means an increasing thrust on educating IETFers, broadly, about security issues. Not just the math, but the whole op-sec envelope.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 6 Sep 2013 13:42:05 -0500

On Sep 6, 2013, at 9:55 AM, Dave Crocker <[email-masked]> wrote:
> 
> In other words, the IETF needs to assume that we don't know what will work for end users and we need to therefore focus more on processing by end /systems/ rather than end /users/.

But we are also end users. I recall being laughed at 6 or 7 years ago when I suggested that email security implementations would "get better" if the IETF insisted on using them for our email. My proposal at the time was, that since we thought S/MIME was the cat's whiskers, we should set up a CA and issue free end-user certs to all participants. Messages to IETF lists would require signing with said certs to be considered valid. This would make it easy to eliminate most of our SPAM.

So, we could eat our own dogfood, with whatever anti-surveillance mechanisms we specify. I am positive that would make things more end-user usable, over time.

--
Dean

---

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Sep 2013 12:32:59 -0700

On 9/6/2013 11:42 AM, Dean Willis wrote:
>> In other words, the IETF needs to assume that we don't know what
>> will work for end users and we need to therefore focus more on
>> processing by end /systems/ rather than end /users/.
>
> But we are also end users.

Mostly we are /not/.

That is... of course we are end-users.  And to the extent that the
target market for something is users similar to "us", then fine.

The problem is when the target market is mass-market end-users.  The 3-4
billion other folk who don't participate in the IETF.  The average IETF
participant is  wildly different from the average mass-market end-user,
in many different ways.  Very many.

> So, we could eat our own dogfood,

Oh we definitely /should/ eat our own dogfood.  If the stuff we produce
is not even usable for us, well then...  And I think we can learn quite
a bit of how to improve things.

But my deeper point is that that is nowhere close to sufficient, for
demonstrating mass-market usability or efficacy.

On 9/6/2013 10:25 AM, Michael Richardson wrote:
> 1) We could be telling the public about the protocols that we
> designed 10, 15, and even 20 years ago. Some of which even have
> rather widespread implementation, but seem to have zero use. (S/MIME
> is in every copy of Outlook and Thunderbird, AFAIK)

To what end?  Their poor uptake clearly demonstrates some basic 
usability deficiencies.  That doesn't get fixed by promotional efforts.

> What would the spam situation be like if 90% of emails were
> regularly signed back in 1999?

You mean the way that postal mail and telephone calls require you to 
authenticate yourself personally before you can use them?

Or the way you have to authenticate yourself before you can buy anything 
in a store?

There are tradeoffs here and they can have very considerable downsides.

d/

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 15:39:08 -0400

> What if they didn't say they were NSA guys, but just discretely worked a weakness into a protocol? What if they were a trusted senior member of the community?

If we have trusted senior members making false statements that can be shown to be false, then they won't get consensus if we do our consensus process right.   So if this has happened in the past, you should be able to find evidence that it has happened.  If you can't find such evidence, I think it's harmful to assume that it has happened.   The IETF process is in principle extremely robust in the face of this kind of behavior.   I encourage you to go looking, but don't descend into madness.

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Sep 2013 16:26:44 -0400

On 09/06/2013 11:46 AM, Ted Lemon wrote:
> The threat model isn't really the NSA per se—if they really want to bug you, they will, and you can't stop them, and that's not a uniformly bad thing. 

I disagree, or at least, I think that your statement conflates two
different threat models.

One kind of threat is that the NSA will bug you specifically.   And yes,
if they consider it important to do so, they very likely will.  There is
almost certainly some vulnerability in your hardware or software or
physical security, and they have lots of resources that can be invested
in finding it.

The other kind of threat, is that NSA will bug you because it's
currently really easy for them to engage in mass surveillance.   Most
traffic isn't even encrypted; and at least some of what is encrypted is
trivially broken.

I don't think IETF can (or should) do much about the former kind of
threat.   Most of it is out of our scope.    But we should be working
hard to address the latter kind of threat.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Sep 2013 08:58:34 +1200

Ted,

> So this isn't an emergency.   It's a teachable moment.   We should pay attention.

Absolutely. I have noted at least 20 messages in the recent flood that
mention useful things the IETF can do, which is exactly what my provocative
message asked for. But (as Bruce's own recent posts show) the main weak spots
are not protocols and algorithms.

      Brian

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 6 Sep 2013 23:06:38 +0200

> Right, because there's no way the NSA could ever pwn the DNS root key.

It is probably easier for NSA or similar agencies in other countries
to coerce X.509 root CA providers that operate on a competetive market
than fooling the entire international DNS black helicopter cabal. But
that is -- I admit -- an educated guess, based on personal relations.

>   - Mitigating single points of failure (IOW, we _cannot_ rely

In effect, DANE exchanges one trust model for another. I happen
to believe that the damage risque is lower with DNSSEC + DANE than the
traditional "any CA can issue a certificate for any domain name" setup.

>   - Trust anchor establishment for sensitive communications

agree on all. 
 
> The threat model isn't really the NSA per se—if they really want to bug you, they will, and you can't stop them, and that's not a uniformly bad thing.   The problem is the breathtakingly irresponsi…
 
Audit and open source seem to be good starting points. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Yow!  It's some people inside the wall!  This is better than mopping!

---

From: David Conrad <[email-masked]>
Date: Fri, 6 Sep 2013 14:34:45 -0700

On Sep 6, 2013, at 2:06 PM, Måns Nilsson <[email-masked]> wrote:
> than fooling the entire international DNS black helicopter cabal. 

Probably the wrong place to apply the paranoia. How much do you trust the AEP Keyper HSM tamperproof blackbox hasn't had a backdoor installed into it at the factory?

> Audit and open source seem to be good starting points. 

Where feasible, sure. Unfortunately, the rabbit hole is deep.  How many billions of transistors are there in commodity chips these days?

Regards,
-drc

---

From: Tim Bray <[email-masked]>
Date: Fri, 6 Sep 2013 15:02:51 -0700

How about a BCP saying conforming implementations of a wide-variety of
security-area RFCs MUST be open-source?

*ducks*

On Fri, Sep 6, 2013 at 2:34 PM, David Conrad <[email-masked]> wrote:

> Probably the wrong place to apply the paranoia. How much do you trust the
> AEP Keyper HSM tamperproof blackbox hasn't had a backdoor installed into it
> at the factory?
>
> Where feasible, sure. Unfortunately, the rabbit hole is deep.  How many
> billions of transistors are there in commodity chips these days?
>
> Regards,
> -drc
>
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 18:05:27 -0400

On Sep 6, 2013, at 6:02 PM, Tim Bray <[email-masked]> wrote:
> How about a BCP saying conforming implementations of a wide-variety of security-area RFCs MUST be open-source?

So clearly we should do all our crypto on devices built out of 7400-series logic.   Hm, where has my old wire-wrap tool gone?

---

From: David Morris <[email-masked]>
Date: Fri, 6 Sep 2013 16:10:16 -0700 (PDT)

> So clearly we should do all our crypto on devices built out of 7400-series logic.   Hm, where has my old wire-wrap tool gone?

Only if you purchased the 7400 stuff 20 years ago so that you know modern 
logic isn't hidden in the 74xx case.

Seriously though, NSA makes a nice villan, but much of our hardware is 
manufactured in counties with fewer restraints than the NSA when it
comes the right to privacy, etc. Wouldn't suprise me that my major
brand router has sniffers from more than one country's security agency.

---

From: Scott Brim <[email-masked]>
Date: Fri, 6 Sep 2013 19:19:14 -0400

On Sep 6, 2013 3:34 PM, "Dave Crocker" <[email-masked]> wrote:
> To what end?  Their poor uptake clearly demonstrates some basic usability
deficiencies.  That doesn't get fixed by promotional efforts.

Or rather, as we've seen in other cases, people just don't see potential
benefits large enough to motivate them.

---

From: SM <[email-masked]>
Date: Fri, 06 Sep 2013 15:59:21 -0700

Hi Tim,
At 15:02 06-09-2013, Tim Bray wrote:
>How about a BCP saying conforming implementations of a wide-variety 
>of security-area RFCs MUST be open-source?

A BCP is not needed to do that.  It is already doable "but we [1] 
know that you [2] are not going to do it".

Speaking of open source, 
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c

>*ducks*

Where?  I don't see any ducks. :-)

Regards,
-sm

1. The word "we" is used in a general context.
1. The word "you" is used in a general context.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Sep 2013 16:35:04 -0700

On 9/6/2013 4:19 PM, Scott Brim wrote:
> On Sep 6, 2013 3:34 PM, "Dave Crocker" <[email-masked]
> <mailto:[email-masked]>> wrote:

Perhaps.  But fundamental usability deficiencies can move these issues 
into the realm that warrants quoting Marshall Rose: "With enough thrust, 
pigs /can/ fly."  Only in this case, it's more like "for some issues, no 
amount of thrust can get this pig into the air."

In other words, considering the issues only in terms of user motivation 
ignores actual basic usability design deficiencies.

Currently, problems with security usability include:

    0. Systems providing very poor information

    1. Systems providing information at very poor times

    2. Users having to know too much

    3. Users having to do too much

Working on user motivation can help a little bit with #3 and none of the 
rest.  It can't help with all of #3 because there are cognitive limits 
that frequently apply.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Sep 2013 20:36:20 -0400

On Fri, Sep 6, 2013 at 9:20 AM, Pete Resnick <[email-masked]>wrote:

>>> insisting that encryption and decryption are transparent. Any email that
>>> can be sent encrypted is sent encrypted.
>>>
>>
>> the time in my work. If only everything were encrypted, then we would be
>> completely safe.
>>
>
> Actually, I disagree that this fallacy is at play here. I think we need to
> separate the concept of end-to-end encryption from authentication when it
> comes to UI transparency. We design UIs now where we get in the user's face
> about doing encryption if we cannot authenticate the other side and we need
> to get over that. In email, we insist that you authenticate the recipient's
> certificate before we allow you to install it and to start encrypting, and
> prefer to send things in the clear until that is done. That's silly and is
> based on the assumption that encryption isn't worth doing *until* we know
> it's going to be done completely safely. We need to separate the trust and
> guarantees of safeness (which require *later* out-of-band verification)
> from the whole endeavor of getting encryption used in the first place.

Actually, let me correct my earlier statement.

I believe that UIs fail because they require too much effort from the user
and they fail because they present too little information. Many times they
do both.

What I have been looking at as short term is how to make sending and
receiving secure email to be ZERO effort and how to make initialization no
more difficult than installing and configuring a regular email app. And I
think I can show how that can be done. And I think that is a part of the
puzzle we can just start going to work on in weeks without having to do
usability studies.

The other part, too little (or inconsistent) information is also a big
problem. Take the email I got from gmail this morning telling me that
someone tried to access my email from Sao Paulo. The message told me to
change my password but did not tell me that the attacker had known my
password. That is a problem of too little information.

The problem security usability often faces is that the usability mafia are
trained how to make things easy to learn in ten minutes because that is how
to sell a product. They are frequently completely clueless when it comes to
making software actually easy to use long term. Apple, Google and Microsoft
are all terrible at this. They all hide information the user needs to know.

I have some ideas on how to fix that problem as well, in fact I wrote a
whole chapter in my book suggesting how to make email security usable by
putting an analog of the corporate letterhead onto emails. But that part is
a longer discussion and focuses on authentication rather than
confidentiality.

The perfect is the enemy of the good. I think that the NSA/GCHQ has often
managed to discourage the use of crypto by pushing the standards community
to make the pudding so rich nobody can eat it.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Sep 2013 08:24:14 +0200

> How about a BCP saying conforming implementations of a wide-variety of security-area RFCs MUST be open-source?

Well, there is something in there that makes sense.

We do have a program in the world called Common Criteria. That certification program includes CCRA (CC Recognition Agreement) that implies that countries that run certification agencies agree that what is certified in one country by one such certification agency is also viewed as certified in all countries.

This makes it possible to go also with closed source items to one such certification agency and get it certified according to a specification.

Now, there are of course (at least) two weaknesses in this:

1. A certification must be against some certification testing. That is not an RFC, but the test itself might though refer to RFCs as for example "a router" is quite complicated and it is specifically important to know it does not do MORE things than what is specified in the certification testing specification.

2. How do one know that the certification agency is not lying.

But I think this (or something similar) is still the best we can do and/or possibly what we should do.

Also with open source software that "claim to implement gPGP" :-)

   Patrik

---

From: Jorge Amodio <[email-masked]>
Date: Sat, 7 Sep 2013 07:33:20 -0500

And who certify such agencies ?

-J

On Sat, Sep 7, 2013 at 1:24 AM, Patrik Fältström <[email-masked]> wrote:

>
>
> We do have a program in the world called Common Criteria. That
> certification program includes CCRA (CC Recognition Agreement) that implies
> that countries that run certification agencies agree that what is certified
> in one country by one such certification agency is also viewed as certified
> in all countries.
>
>
>

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Sep 2013 15:12:28 +0200

> And who certify such agencies ?

Today the governments, and by mutual cooperation.

That said, I think we need a generic way to have oversight over _any_ process. Including oversight where the review is done under NDA.

In many countries that kind of oversight is by having (for example in Sweden) the Parliament appoint an independent body that do have insight in the police wiretap orders. Is that good enough? I do not know.

But that is sort of my point. If we manage to design how to ensure things are done as they are announced, then we have solved many of the problems.

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Sep 2013 09:39:43 -0400

> security-area RFCs MUST be open-source?

And the user MUST compile them themselves from the sources?

Nobody runs open source, (unless its an interpreted language). They run the
compiled version and there is no infrastructure to check up on the
compilation.

Nor does being open source provide any additional security, only review
provides security and it is hard enough getting people to review other
people's code when you pay them to do that. Expecting people to spend their
time reviewing other people's code for fun is naive. Kerberos had a major
architectural flaw that went unnoticed for over a decade.

---

From: [email-masked]
Date: Sat, 07 Sep 2013 07:07:40 -0700 (PDT)

> compiled version and there is no infrastructure to check up on the

And don't forget:

   http://cm.bell-labs.com/who/ken/trust.html

				Ned

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Sep 2013 10:45:24 -0400

On Sep 7, 2013, at 9:39 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> Nor does being open source provide any additional security, only review provides security and it is hard enough getting people to review other people's code when you pay them to do that. Expecting people to spend their time reviewing other people's code for fun is naive. Kerberos had a major architectural flaw that went unnoticed for over a decade.

On the contrary, I used to suffer through security audits on ISC DHCP code back in the day; people were doing this entirely on a volunteer basis.   I think it's incorrect to suggest that open source code doesn't get audited, and indeed it's likely that it gets audited more thoroughly and more usefully than a lot of closed source code.

It really depends on the setting.   My own company sells closed-source code; Andrea asked me the other night whether I thought there might be something scary in the code.   I thought about it, and concluded that it was unlikely, because we have a very small, tight team, and everybody sees all commits.   I think it would be difficult to suborn our code without everyone on the team knowing about it, and knowing who is on the team, that would quickly be the rest of the world.

An open source project with a less tight team, or a completely suborned team, might be far less trustworthy.   But another closed-source project might be far worse, if for example the repository were so big that nobody watched all commits, and the set of committers so large that it would be easy to suborn one of them.

I think the only rule you can go by here is caveat emptor, whether the code is open or closed.   You need to actually figure out who you are doing business with.

As for compilation versus source, that's a real issue, but open source is a clear win here, because you have both the input and the output, and you can compare them.   Here, an open source project with a clear build process that is replicable is a huge win over one that is complex and wonderful and non-replicable. Knowing quite a few of the latter, I hope to see improvements that some increased paranoia might yield as people flock to the more verifiable builds, and the projects with poor build processes fix them.

---

From: SM <[email-masked]>
Date: Sun, 08 Sep 2013 00:21:38 -0700

Hi David,
>brand router has sniffers from more than one country's security agency.

The right to privacy is mentioned in the above.  From 
http://www.europarl.europa.eu/sides/getDoc.do?type=MOTION&reference=B7-2013-0342&language=EN

   "whereas the US legal system does not ensure the protection of non-US
    citizens, such as EU citizens; whereas, for instance, the protection
    provided by the Fourth Amendment applies only to US citizens and not
    to EU citizens or other non-US citizens;"

There aren't any villains in all this.  There is a question of 
whether the company taking the data will value each of its customers 
equably when it comes to privacy.  It doesn't seem so.

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Sep 2013 08:14:07 -0400

On Sun, Sep 8, 2013 at 3:21 AM, SM <[email-masked]> wrote:

> http://www.europarl.europa.eu/**sides/getDoc.do?type=MOTION&**
> reference=B7-2013-0342&**language=EN<http://www.europarl.europa.eu/sides/getDoc.do?type=MOTION&reference=B7-2013-0342&language=EN>
>
> There aren't any villains in all this.  There is a question of whether the
> company taking the data will value each of its customers equably when it
> comes to privacy.  It doesn't seem so.
>

The other countries concerned did not take the lead in establishing a
network of secret prisons where hundreds of prisoners were illegally held
without charge. As the US did under President Bush.

The other countries concerned did not employ torture as the US did under
President Bush.

Another worrying aspect of BULLRUN is that it is named after a victory for
the confederate side in the US civil war. They seem to be looking to make
slaves out of us. They certainly seem to be endorsing a racist cause. What
should we think if the German intelligence service had a similar program
codenamed AUSCHWITZ?

We know from the history of Snowden that the NSA has lax internal controls.
They allowed a person who wasn't even an employee access to this
information. They have since chased Snowden off to Russia where Putin
professes to be concerned that he does not leak any more information. Could
this be because Putin has infiltrated one or more Snowdens into the NSA
himself and does not want to see the intel gathered to date be compromised
or because he thinks he can probably get it out of Snowden if the GRU can
find the right stripper.

There might be other agencies that have compromised the Internet to the
same extent as the NSA. Or the others might just find it is easier to free
ride of the NSA work product which Russia and China and Iran are all
consuming through their own moles.

---

From: Jorge Amodio <[email-masked]>
Date: Sun, 8 Sep 2013 09:07:03 -0500

President Bush.

You mean like Pakistan, Iran, Libya, Syria, Saudi Arabia ....

-J

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Sep 2013 11:13:44 -0400

> You mean like Pakistan, Iran, Libya, Syria, Saudi Arabia ....

My original comment was limited to adversaries with potential intercept
capability.

If it is the case that we have to be concerned about a widespread intercept
capability by those countries in the US then the intelligence agencies have
completely failed in their mission to defend NATO countries.

China on the other hand, well we all outsource manufacture there.

Of course there are despotic regimes that also use torture. The point I was
making is that alone in the free world the US administration decided to
sanction war crimes and it appears from their choice of codenames that the
people in charge of this program might be the type of people who put
confederate flags on their cars.

So 'just trust us we are the good guys' does not have the same rhetorical
force that it once did.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 08 Sep 2013 12:19:42 -0400

On Sunday, September 08, 2013 11:13:44 Phillip Hallam-Baker wrote:
...
> might be the type of people who put confederate flags on their cars.
...

Since Bull Run is the Union name for the battle, probably not (It'd have been 
Manassas from a Confederate perspective).  

Scott K

P. S.  We are rather far afield for the IETF list, so I'm not going to jump in 
on this particular angle further.

---

From: SM <[email-masked]>
Date: Sun, 08 Sep 2013 10:37:34 -0700

>You mean like Pakistan, Iran, Libya, Syria, Saudi Arabia ....

There were people from Pakistan who participated in the IETF.  I 
recall an email exchange where a person from that country received an 
unpleasant comment from someone who is part of the IETF "leadership".

In my opinion a discussion about Country X or Country Y would take 
the thread downhill.  It can also have a chilling effect.

At 05:14 08-09-2013, Phillip Hallam-Baker wrote:
>Another worrying aspect of [censored] is that it is named 
>after[censored]. They seem to be looking to make [censored] out of 
>us. They certainly seem to be endorsing [censored]. What should we 
>think if the [censored] had a similar program codenamed [censored]?

It would not look good.

Regards,
-sm

---

From: joel jaeggli <[email-masked]>
Date: Sun, 08 Sep 2013 11:59:13 -0700

On 9/8/13 10:37 AM, SM wrote:
> There were people from Pakistan who participated in the IETF.  I recall
> an email exchange where a person from that country received an
> In my opinion a discussion about Country X or Country Y would take the
> thread downhill.  It can also have a chilling effect.

State employment of legal and extra-legal means to spy on and capitalize
the activities of their own citizens and those of other states is
something that transcends boundries, cultural identity or ideology. It
doesn't much matter if you're David Dellinger, Neda Agha Sultan, Khalid
El-Masri, etc, if you'd ended up on the wrong side of a state apparatus,
well you're going to have a bad time of it.

Should your tools, the contents of your mind, and the various effects
and context of your personal communication become instruments of
state-power? Because the tools we've built are certainly capable of that.

>> after[censored]. They seem to be looking to make [censored] out of us.
>> They certainly seem to be endorsing [censored]. What should we think
>> if the [censored] had a similar program codenamed [censored]?
> 
> It would not look good.
> 
> Regards,
> -sm

---

From: Janet P Gunn <[email-masked]>
Date: Sun, 8 Sep 2013 16:34:03 -0400

[email-masked] wrote on 09/08/2013 08:14:07 AM:

> From: Phillip Hallam-Baker <[email-masked]>

> 
> Another worrying aspect of BULLRUN is that it is named after a 
> victory for the confederate side in the US civil war.

But the battles are only called the (First or Second) Battle of Bull Run 
by the NORTH, which lost them.

The SOUTHerners who won the battle, as well as the now-local residents of 
Northern Virginia, refer to them as the Battle of (First or Second) 
Manassas.

To the locals, Bull Run is simply a local creek which happens to run 
through the battle field.
]
Janet

---

From: <[email-masked]>
Date: Sun, 8 Sep 2013 22:32:47 +0100

http://www.mail-archive.com/[email-masked]/msg12325.html

That's a pretty damning indictment of the development of IPSec from John Gilmore.

Lloyd Wood
http://sat-net.com/L.Wood

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Sep 2013 20:03:31 -0400

> Yes, but there are some compensating pluses:

Please note that I didn't say "worse", only "not significantly
better".  

> You can get a meaningful improvement to your security by good
> choice of registrar (and registry if you have flexibility in
> your choice of name). Other weak registries and registrars
> don't reduce your DNSSEC security, whereas PKIX is only as
> secure as the weakest CA.

Yes and no.  Certainly I can improve my security as you note.  I
can also improve the security of a traditional certificate by
selecting from only those CAs who require a high degree of
assurance that I am who I say I am.  But, from the standpoint of
a casual user using readily-available and understandable tools
(see my recent note) and encountering a key or signature from
someone she doesn't know already, there is little or no way to
tell whether the owner of that key used a reliable registrar or
a sleazy one or, for the PKI case, a high-assurance and reliable
CA or one whose certification criterion is the applicant's
ability to pay.  There are still differences and I don't mean to
dismiss them.I just don't think we should exaggerate their
significance.

And, yes, part of what I'm concerned about is the very ugly
problem of whether, if I encounter an email address and key for
[email-masked] or, (slightly) worse, in one of the
thousand new TLDs that ICANN assures us will improve the quality
of their lives, how I determine whether that is you, some other
Tony Finch who claims expertise in email, or Betty Attacker
Bloggs pretending to be one of you.  As Pete has suggested, one
way to do that is to set up an encrypted connection without
worrying much about authentication and then quiz each other
about things that Tony(2), Betty, or John(2) are unlikely to
know until we are confident enough for the purposes.  But,
otherwise....

By contrast, if I know a priori that the Tony Finch I'm
concerned about is the person who controls dotat.at and you know
that the John Klensin you are concerned about is the person who
controls jck.com, and both of us are using addresses in those
domains with which we have been familiar for years, then the
task is much easier with either a PKI or DANE -- and certainly
more convenient and reliable with the latter because we know
each other well enough, even if mostly virtually, to be
confident that the other is unlikely to be dealing with
registrars or registries who would deliberately enable domain or
key impersonation.  Nor would either of us be likely to be quiet
about such practices if they were discovered.

> An attacker can use a compromise of your DNS infrastructure to
> get a certificate from a conventional CA, just as much as they
> could compromise DNSSEC-based service authentication.

Exactly.  Again, my point in this note and the one I sent to the
list earlier today about the PGP-PKI relationship is that we
should understand and take advantage of the differences among
systems if and when we can, but that it is a bad idea to
exaggerate those advantages or differences.

    john

---

From: SM <[email-masked]>
Date: Sun, 08 Sep 2013 16:36:26 -0700

Hi Joel,
>state-power? Because the tools we've built are certainly capable of that.

Yes.  That's not a good motivation to give up on privacy though.

Regards,
-sm

---

From: joel jaeggli <[email-masked]>
Date: Sun, 08 Sep 2013 22:25:04 -0700

> Yes.  That's not a good motivation to give up on privacy though.

It is not. That said, the chickens are coming home to roost.

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 07:06:54 +0100

...and a rebuttal from Jeff Schiller.

http://www.mail-archive.com/[email-masked]/msg12497.html

Pass the popcorn.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: 08 September 2013 22:32
Cc: [email-masked]
Subject: RE: Bruce Schneier's Proposal to dedicate November meeting to  saving  the Internet from the NSA

Lloyd Wood

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 9 Sep 2013 01:20:34 -0700

So, has Bruce Schneier actually been invited to speak at the Technical Plenary (or elsewhere) during the Vancouver IETF?  I recall him giving an informative talk at least one previous Tech Plenary, and in light of his 'proposal', if would be interesting to hear what he believes to be broken, and what the IETF might be able to do to help fix it.

	Ross.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Sep 2013 10:29:56 +0200

We're talking.

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Mon, 9 Sep 2013 18:02:27 +0800

Yes. 

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 06 Sep 2013 21:51:20 -0700

> Exactly, and that is not actionable in the IETF.

Brian,

Some years back when we saw the lack of IPv6 deployment we started with 
some IPv4-free plenary time slots - eating our own dog food. Thus I 
think we can do something even on the deployment front.

Wouldn't it make sense for us to do something similar in this space? 
That would help iron out implementation and usability issues.

Regards,
    Erik

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 11 Sep 2013 11:57:41 +0200

I agree with you SM, politics and considering countries names in that
way, that is out of scope of IETF. Comments below,

AB

> unpleasant comment from someone who is part of the IETF "leadership".

That is rude behavior, which I may experienced in IETF.
> the thread downhill.  It can also have a chilling effect.

I totally agree, by having more participants from all world's
countries, makes the IETF more diverse, and by silence to such rude
behavior means we are welcoming less diversity.
>>think if the [censored] had a similar program codenamed [censored]?

It is not good behavior if IETF just watches lists and does not make
mentoring to its participants old/new comers.

AB

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 15 Sep 2013 14:10:22 +0100

>> So, has Bruce Schneier actually been invited to speak at the Technical Plenary (or elsewhere) during the Vancouver IETF?  I recall him giving an informative talk at least one previous Tech Plenary…

A small comment: actually I would like to (read: expect to) read what he
(and others) believe to be broken _before_ the next Plenary and giving a
speak there. And as specific and constructive as possible. That way we
will be much more effective talking about issues at the plenary and
starting stuff at WGs.

Best regards, Tobias

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 15 Sep 2013 14:16:45 +0100

> understanding of privacy considerations.

I am not sure that the "mandatory security and privacy considerations
section" in every draft would be sufficient. IMHO a number of issues
arise from the combination of various standards/technologies and that we
are sometimes missing a few but important pieces (e.g. stuff WGs said we
do "later" or which were seen as "nice to have" or "optional", and then
never happened...).

So although I think privacy concerns should be addressed in every draft,
I also think this goes into the architecture domain across a number of
technologies.

Best regards, Tobias

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 15 Sep 2013 09:48:35 -0400

On Sun, Sep 15, 2013 at 9:10 AM, Tobias Gondrom
<[email-masked]>wrote:

> speak there. And as specific and constructive as possible. That way we will
> be much more effective talking about issues at the plenary and starting
> stuff at WGs.
>

Quite, pointing out what is broken is exactly the type of contribution
Schneier could make. He is very good at spotting holes in security schemes.
I must say I am a little annoyed by his approach. He could deign to post on
the IETF lists himself rather than give oracular statements and then take
the credit.

Security is all about risk mitigation, not risk elimination, as I argued to
Bruce in the wake of his 15 risks of PKI article before he wrote Secrets
and Lies. Security design means tradeoffs and designing to mitigate the
chief risks. Unlike generals who can spend millions of tax payer dollars
making their operations room look like the bridge of the Enterprise, I have
to consider resources.

We do have several areas where we could make significant advances however:

1) Technical improvements to TLS such as recommending sites turn on PFS by
default and remove weak ciphers.

2) Stop sending authentication cookies in the clear whether or not they are
sent inside an encrypted tunnel.

http://tools.ietf.org/html/draft-hallambaker-httpsession-01

3) Fix the missing 5% that stops people using secure email. We have PGP
that has mindshare and S/MIME that has deployment and both are too much
trouble for most IETF people to use, let alone the typical Internet user.
We can and should fix that.

Phill