Subject: [perpass] Howdy!

From: Dean Willis <[email-masked]>
Date: Mon, 2 Sep 2013 11:08:25 -0500

St. Peter redirected me here, which list had escaped my attention. I'm
hoping it's a raging hotbed of subversive or at least somewhat paranoid
activity. Because we really ought to be quite worried by now.

And yes, this is really just a test message to see if I can hear myself.

--
Dean

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Sep 2013 19:55:33 +0100

Hi Dean,

> activity. Because we really ought to be quite worried by now.

So, given you've been thinking about this for maybe longer than most
I'm wondering if you have any specific protocol changes or additions
you'd suggest, or descriptions of new threat models that could be useful
to WGs developing or maintaining protocols? IMO, things like that would
be most useful for now.

> And yes, this is really just a test message to see if I can hear myself.

It worked:-)

Cheers,
S.

> 
> --
> Dean
> 
> 
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Sep 2013 20:24:47 +0000

On Sep 2, 2013, at 7:08 PM, Dean Willis <[email-masked]> wrote:

> St. Peter redirected me here, which list had escaped my attention. I'm hoping it's a raging hotbed of subversive or at least somewhat paranoid activity.

Half of us are subversive; the other half are spooks spying on the subversive element. The question is, do you know which is which?

> Because we really ought to be quite worried by now.
> 

Yeah, you can hear yourself. Also, *they* can hear you. OK. That's not too difficult on a public mailing list with a public archive.

We can't each and every one of us defeat the well-funded, well-equipped, and well trained adversaries who are willing to go to great lengths to spy on us. At worst, they can break into your home ([1]). But that kind of expense doesn't scale. Even the TLAs don't have the resources to do this to billions or even millions of people. 

If we can raise the bar so that their resources are only enough to spy on, say, 100,000 people, then I (please forgive me for being so self-centered), and probably you, are off the hook. There's likely to be at least 100,000 people who are perceived to be more dangerous to whatever country's national security. Yeah, it still sucks to be number 99.999 on this list of alleged criminals and terrorists, but it's way better for the rest of us.

So the question remains, do we have the ability to allow private communications between parties, such that the protection won't stand out? Can we allow anonymous or pseudonymous public speaking that won't be traceable by technological means? Can we make it so that Internet-based services default to private?

Pretty much no constitution or declaration of rights protects people against surveillance. That is because surveillance used to be so expensive, that it was never abused or done on a large scale. Compare that to the US 3rd amendment, prohibiting the quartering of soldiers in private houses. Nobody would prohibit this today, because it's just not done anymore, but it probably was in those days. Perhaps the right to be free from mass surveillance, both governmental and private without due process should be codified in national constitutions, but that is not something that the IETF has any say in. 

Yoav

[1] http://www.foreignpolicy.com/articles/2013/07/16/the_cias_new_black_bag_is_digital_nsa_cooperation

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Sep 2013 20:23:58 -0500

> to WGs developing or maintaining protocols? IMO, things like that would

I think there are a couple of principles that we need to adopt IETF-wide.

Part of the definition of "good Internet citizen" for a protocol or application is that not only does that protocol/application include anti-surveillance principles for itself, but that it helps OTHER protocols avoid surveillance. Surveillance-resistance is MORE IMPORTANT than optimizing transport efficiency.

So, a couple of rules, probably badly organized:

1) Everything SHOULD be encrypted, unless there is an absolute operational requirement not to. This means "encryption by default" in new protocols, and not even specifying unencrypted operations modes unless necessary. Older protocol specs still in use should be revised to require encryption. Deprecate the non "s" versions of protocols.

2) Well-known ports should be avoided. Or overloaded to the point where the port number is no longer a significant indicator to the application. This gives rise to the "everything over 443" mentality, which we need to find a way to handle gracefully. Demuxing the service within the channel is a better idea than I used to think.

3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size by padding small ones. I like random better, but there might well be some hardware optimizations around fixed packet sizes.

4) Every protocol spec needs to include a pseudonymous usage model, and most should include an anonymous usage model.

5) New protocols should be built around end-to-end crypto rather than relying on transport-level wrappers for everything. It's too easy to use a compromised CA-cert to dynamically build a TLS proxy cert. Some level of key delivery out-of-band, coupled to in-band footprint verification, is probably needed. zRTP is a good model.

6) Randomizing interpacket timing is useful. This does all sorts of horrible things to both TCP optimization and the jitter buffers in real-time communications. But it's worth it. Remember, surveillance-resistance is MORE IMPORTANT than efficiency.

7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons we should learn. So does TOR.

8) Every piece of crypto-advice needs serious, multiparty, international, and aggressive review. No more documents authored by NSA shills (which Schneier says we seem to have).

--
Dean

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Sep 2013 20:52:42 +0100

Hi Dean,

My bet would be that some some but not all of those might fly.

Others opinions?

S.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 6 Sep 2013 16:01:56 -0400

Hi,

I agree, some are great suggestions.  However, I don't think the use of well-known ports matter that much.  Proxy firewalls know how to detect and decipher protocols regardless of the port the protocol is sent over.  We have been aware of those capabilities as well as the MITM capabilities of products (firewalls, load balancers, etc.) for quite some time, but just accepted them in corporate settings or limited what we do/did from those environments.

I am also thinking more about information sharing and object level security since I co-chair MILE.  In RID, RFC6545 Section 9.1, it describes how to apply object level security specific to traffic over RID.  Many of us know that you can cite sections of an RFC, but not everyone knows that.  I am wondering if it would be helpful for me to write a generic version of that section (updating it where needed) to apply to any XML schema and any form of transport.  If so, I'll get that ready for the cut off.  This could be used by SACM as well, maybe other groups too.

The draft Matt Miller is working on addresses object level security for XMPP, so you may not need what I described for XMPP...

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, September 06, 2013 3:53 PM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [perpass] Howdy!

Hi Dean,

Others opinions?

S.

On 09/06/2013 02:23 AM, Dean Willis wrote:
>> you'd suggest, or descriptions of new threat models that could be 
>> useful to WGs developing or maintaining protocols? IMO, things like 
>> that would be most useful for now.
>>
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 06 Sep 2013 16:40:33 -0400

Hi Stephen:

The list below does not necessarily consider trade-offs that may be less 
relevant for unconstrained networks, but that could be very important 
for constrained networks (where most devices can be expected to be 
longer term).

Some general notes:
- Randomizing packet length would be prohibitively expensive in 
energy-starved environments [e.g., with devices that depend on energy 
harvesting for their operation] and, perhaps, from a global climate 
change perspective [with about 2% of world energy consumption currently 
due to internet-related operations]).
- One has to consider that each device may have to transgress from a 
state where it does not having any shared state with the network towards 
a state where it would (e.g., when joining a new network). So, one can 
expect differentiation in delivered security services to stay.
- Inline or online centralized network management functionality may have 
to be traded for more decentralized/distributed network functionality. 
This may have major repercussions for OCSP, CRLs, DNS, etc, etc.
The list goes on and on ...

I speculate that the largest risks would not so much with the crypto 
constructs themselves, but more so with security policy management, 
initial keying and certification of device keys (esp. if key pairs are 
generated outside the device), privacy/traceability concerns, and 
concerns re implementation attacks (side channel and fault attacks).

As a final note: even with changes to IETF protocols incorporating ideas 
from the list, this would not have stopped problems with some existing 
IETF protocols, where changes to unfortunate choices (case in point: 
invited talk Crypto 2013 on "why the world is still running on RC4") are 
slow. This is just to say that any change to the status quo is hard (and 
not all is of NSA's making).

Rene

>> 1) Everything SHOULD be encrypted, unless there is an absolute operational requirement not to. This means "encryption by default" in new protocols, and not even specifying unencrypted operations m…
RS>>
One always needs to accommodate devices that may have to transgress from 
the state of having no shared state to having this shared state, e.g., 
when a fresh device wishes to join a new network.

Using ephemeral aliases of Identifiers of communicating parties would 
make collecting traffic patterns much harder.
<<RS
>> 3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size b…
RS>>
This might significantly increase the energy cost of packet 
transmissions in constrained network data and would be uneconomical in 
constrained networks, esp. if devices are powered using energy harvesting.
<<RS

  4) Every protocol spec needs to include a pseudonymous usage model, 
and most should include an anonymous usage model. 5) New protocols 
should be built around end-to-end crypto rather than relying on 
transport-level wrappers for everything. It's too easy to use a 
compromised CA-cert to dynamically build a TLS proxy cert. Some level of 
key delivery out-of-band, coupled to in-band footprint verification, is 
probably needed. zRTP is a good model.

6) Randomizing interpacket timing is useful. This does all sorts of 
horrible things to both TCP optimization and the jitter buffers in 
real-time communications. But it's worth it. Remember, 
surveillance-resistance is MORE IMPORTANT than efficiency.

7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have 
lessons we should learn. So does TOR.

8) Every piece of crypto-advice needs serious, multiparty, 
international, and aggressive review. No more documents authored by NSA 
shills (which Schneier says we seem to have).

RS>>
Obviously, use of cryptographic techniques should be conditional on 
proper review and careful analysis of

Well, all change may harm vested interests (see the Crypto/CHES invited 
talk on "why the world is still using RC4").
<<RS

-- Dean

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Sep 2013 14:48:25 -0400

Stephen,

Since you solicited feedback ...

We have had considerable, recent, experience with the need to avoid 
adding delay to a user's web experience (e.g., "Happy Eyeballs") in the 
v4/v6 transition context. Suggestions that we increase delay in favor of 
security are not likely to be well received by users or service providers.
>> Part of the definition of "good Internet citizen" for a protocol or application is that not only does that protocol/application include anti-surveillance principles for itself, but that it helps O…
given the quantity of meta-data (and personal data) collected by Google, 
Facebook,
and many other commercial entities, and the willingness of users to 
supply such data, it's hard to believe that most users would agree with 
this statement.
>> 1) Everything SHOULD be encrypted, unless there is an absolute operational requirement not to. This means "encryption by default" in new protocols, and not even specifying unencrypted operations m…
One of the reasons many enterprises decline to employ e-t-e encryption 
within their
nets is because it interferes with debugging and scanning of traffic for 
malware. While
I am in favor of mandatory to implement encryption for our protocols, 
mandatory to use
is not a good idea in all cases.
>> 2) Well-known ports should be avoided. Or overloaded to the point where the port number is no longer a significant indicator to the application. This gives rise to the "everything over 443" mental…
others have already noted that this is a bad idea from a protocol 
perspective. in an era when many folks try to minimize the number of 
round trips needed to provide a service to a user, this add to the 
total. again, while security folks might see this as attractive, I
doubt that many users and service providers wold agree.
>> 3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size b…
we have long understood what it takes to provide TFS, and nobody has 
wanted to waste the bandwidth to do it properly. I doubt that this view 
has changed.
>> 4) Every protocol spec needs to include a pseudonymous usage model, and most should include an anonymous usage model.
Use of pseudonyms is applicable to very few of our protocols, and most 
of the ones where it
is applicable, it is already satisfied. Anonymous use, depending on the 
definition one
uses, may be easy or nearly impossible.
>> 5) New protocols should be built around end-to-end crypto rather than relying on transport-level wrappers for everything. It's too easy to use a compromised CA-cert to dynamically build a TLS prox…
see comments above re #1.
>> 6) Randomizing interpacket timing is useful. This does all sorts of horrible things to both TCP optimization and the jitter buffers in real-time communications. But it's worth it. Remember, survei…
not, it's not worth it. see comment above re #3.
>> 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons we should learn. So does TOR.
DTN is great for the interplanetary Internet. I prefer realtime 
performance for almost all of my Earth-bound Internet apps. I suspect 
other users fell the same way. P2P is fine
for some apps, but not all, maybe not even many.
>> 8) Every piece of crypto-advice needs serious, multiparty, international, and aggressive review. No more documents authored by NSA shills (which Schneier says we seem to have).
I think we have generally good review for the algs we choose; we 
periodically review algs and key sizes and make revisions as deemed 
necessary. We have folks like David McGrew (Cisco) providing much of 
this expert review. I think we have operated in this mode for many years.

Steve

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Sep 2013 21:43:39 +0300

Hi Dean,

I wanted to comment on your suggestions:

 > 1) Everything SHOULD be encrypted, unless there is an absolute 
operational requirement not to. This means "encryption by default" in 
new protocols, and not even specifying unencrypted operations modes 
unless necessary. Older protocol specs still in use should be revised to 
require encryption. Deprecate the non "s" versions of protocols.

I guess there are two issues here, namely:

  * End-to-end vs. Hop-by-hop (or stuff in between)

  * Encryption itself is often not the problem but rather the key management

As you have seen my post about the VoIP stuff it is actually not so easy 
to say what exactly has to be done in what situations since our 
protocols are a bit more complex...

So, you will have to expand a bit. Maybe you also want to explain the 
SHOULD vs. a MUST.

 >
 > 2) Well-known ports should be avoided. Or overloaded to the point 
where the port number is no longer a significant indicator to the 
application. This gives rise to the "everything over 443" mentality, 
which we need to find a way to handle gracefully. Demuxing the service 
within the channel is a better idea than I used to think.

That does not make sense. We are heading in the direction of everything 
running on 443 with TLS (from a standardization point of view) -- not 
necessarily on the deployment side (since otherwise we wouldn't need 
efforts like those from EFF).

You might also find it interesting to hear that the ability for 
demultiplexing HTTP 2.0 and earlier version will be done based on 
information in the TLS handshake and that the TLS group had decided that 
they prefer a solution that reveals the type of application and rejected 
a proposal for hiding it.

Here are the two proposals:
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04

Maybe it would be worthwhile to revisit the decision?

(A side remark: I was at that meeting and pointed out that this is a 
privacy decision and folks in the room said that this has nothing to do 
with privacy....)

 >
 > 3) Packet sizes should be variable, preferably random. This is the 
opposite of the "discover the MTU and fill every packet" model of 
efficiency. Or, we could make all packets the same fixed size by padding 
small ones. I like random better, but there might well be some hardware 
optimizations around fixed packet sizes.

Ok. Sounds reasonable to have that option. I know that IPsec has the 
ability to add padding.

 > 4) Every protocol spec needs to include a pseudonymous usage model, 
and most should include an anonymous usage model.

Makes sense to me (at least for protocols that are potentially run by 
end devices). For some protocols I guess it is less useful (thinking 
about routing protocols).

Here is the challenge: If I look at SIP then we certainly have that 
option but
a) you will have to get providers to implement it, and
b) the functionality often conflicts with other privacy features.

For example, you may not want to get interrupted with a phone call when 
you do not know the person on the other end.

 >
 > 5) New protocols should be built around end-to-end crypto rather than 
relying on transport-level wrappers for everything. It's too easy to use 
a compromised CA-cert to dynamically build a TLS proxy cert. Some level 
of key delivery out-of-band, coupled to in-band footprint verification, 
is probably needed. zRTP is a good model.

I think they should have both since the functions provided are actually 
different.

ZRTP is not a good model if you don't know the voice of the other 
person. Not all communication is (a) between persons, (b) between 
persons who use voice communication, and (b) persons who know each other.

Need to think about that.

In case of Tor we could certainly learn something about fingerprinting 
avoidance. I am not sure about the lessons you have learned from the 
other efforts. Our IETF p2p efforts are still in a dying state since the 
entire industry has unfortunately changed their preferred communication 
model in the meanwhile from p2p to client-to-server for pretty much 
everything.

In my VoIP blog post I argued that TURN doesn't actually give you any 
additional privacy protection if the adversary is a powerful 
eavesdropper or the VoIP provider itself. It only helps when you want to 
hide your IP address towards the communication party, as Shida explained 
in his SIP privacy RFC.

I agree with you about the standardization aspects (regarding openness 
and transparency). The problem is that with the Web world we are 
unfortunately heading into a different direction, as we (=IAB) tried to 
explain some time ago with the 'post standardization' plenary 
(+document). I am not sure yet how to best tackle that story (and I am 
unfortunately not entirely alone with my lack of suggestions).

On the second suggestion I don't think you are serious. We obviously 
have documents co-authored by NSA employees (see 
http://www.arkko.com/tools/allstats/c_nsa.html) but first I dislike to 
exclude people (since that's the whole point of having an open standards 
process) and second where do you stop excluding? We have people who are 
contracting for the NSA, we have people who work at government 
organizations (like NIST), we have companies who work on government 
contracts (like BBN).

Ciao
Hannes

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 10 Sep 2013 14:55:44 -0400

On Tue, Sep 10, 2013 at 09:43:39PM +0300, Hannes Tschofenig wrote:
> operational requirement not to. This means "encryption by default"
> in new protocols, and not even specifying unencrypted operations
> modes unless necessary....
> 

Also, perfect forward secrecy (PFS) versus non-PFS.  If we are going
to make encryption a SHOULD or a MUST, so should be PFS.  Even if the
key management is a problem, or worse, let's suppose the NSA has the
private keys for a number of the major CA's, if everything is using
PFS, then an attacker who is interested in doing bulk surveillance
will have to MITM all of the traffic.  That will take a large amount
of power and cooling, so it becomes a lot more expensive to do bulk
surveillance, and it will also be much, MUCH harder to do it covertly
(you can't just hide a box in a telephone closet somewhere; but rather
racks and racks of servers at Tier 1 NAP's will be required).

OF course, there will be some things where encryption is simply not
needed, and but data integrity is is needed.  Example: time (NTP) and
routing protocols.   So we need to be careful how we specify MUST.  :-)

		     	   	      - Ted

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 13 Sep 2013 08:57:10 +0000

> racks and racks of servers at Tier 1 NAP's will be required).

I completely agree. I think that MUST is a reasonable requirement for
core internet protocols.

> routing protocols.   So we need to be careful how we specify MUST.  :-)

I think this is a reasonable read but I'd like to encourage dissent
here. Time is a very important part of almost all cryptographic
protocols - if an attacker is able to distinguish queries about time
from other queries, it allows the attacker to discriminate and thus to
tamper with time related protocols. This is especially true when the
system in question may not have a properly sync'ed clock.

I hacked together a solution for network time that gives most of these
properties - tlsdate ( https://github.com/ioerror/tlsdate/ ) - and it is
used by ChromeOS rather than using the traditional NTP protocol. It has
some downsides (32bit time rather than 64bit time resolution) but
overall, it allows for all of the properties of TLS without any of the
weird downsides of the ancient NTP protocol, of which there are many...

As an example - DNSSEC requires a sync'ed clock and in theory, one
argument goes: no one needs query privacy in DNSSEC, after all, one just
connects directly so an attacker will learn what you learned anyway,
right? However, one needs query privacy to ensure that an attacker
cannot tell that your DNSSEC client is currently trying to learn the
time, thus all other queries are vulnerable to a replay attack or worse.
So really, query privacy, even for data that appears to only need
integrity is really essential. Give the attackers nothing for free -
make them tamper to get even a single bit of information more. This
gives us agency to detect and to take counter actions.

All the best,
Jacob

---

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

> system in question may not have a properly sync'ed clock.

I concur. Unless you have a VERY hard reason NOT to encrypt, then encrypt. Even if it does nothing for you, it helps mask other encrypted traffic.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Sep 2013 11:28:55 -0500

> racks and racks of servers at Tier 1 NAP's will be required).

Sounds reasonable.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Sep 2013 12:12:40 -0500

On Sep 9, 2013, at 1:48 PM, Stephen Kent <[email-masked]> wrote:

> We have had considerable, recent, experience with the need to avoid adding delay to a user's web experience (e.g., "Happy Eyeballs") in the v4/v6 transition context. Suggestions that we increase delay in favor of security are not likely to be well received by users or service providers.

Too bad. We can try to minimize the impact, but a net that gets you killed because the wrong person heard you say the wrong thing is worse than one with slightly less bandwidth or temporal QoS.

> given the quantity of meta-data (and personal data) collected by Google, Facebook,
> and many other commercial entities, and the willingness of users to supply such data, it's hard to believe that most users would agree with this statement.

Perhaps. But unless one accepts it as a principle, one is doomed to build surveillance-friendly networks.

> One of the reasons many enterprises decline to employ e-t-e encryption within their
> nets is because it interferes with debugging and scanning of traffic for malware. While
> I am in favor of mandatory to implement encryption for our protocols, mandatory to use

I've been enterprise IT. And enterprise security. Most of their security problems come form their own people abusing the loopholes. Sure, the IT department is lazy. But once the "generally accepted best practices" require e2e, they'll play along. remember, corporate policies are driven by generally accepted best practices such as GAAP for accounting.

Note that, at least under US law, the management of a corporation is subject to legal attacks from shareholders for losses related to the failure to deploy generally accepted best practices for information security.

 A listing of best practies is here:

http://www.wpi.edu/academics/CCC/Policies/bestpractices.html

Note that they're written by people like CDT (an officer of which edited our privacy RFC), NIST, and other bodies that we influence.

An Internet BCP can go a long way in addressing these things.

> others have already noted that this is a bad idea from a protocol perspective. in an era when many folks try to minimize the number of round trips needed to provide a service to a user, this add to the total. again, while security folks might see this as attractive, I

Everybody wants something for nothing. See Best Current Practices.

> we have long understood what it takes to provide TFS, and nobody has wanted to waste the bandwidth to do it properly. I doubt that this view has changed.

Should it? Who funds BBN, anyhow? What's your motivation for making choices that increase surveillance? 

Yeah, that's an ad hominem attack . But we're going to get a lot of those, and need to have a great deal of confidence in our answers. "Nobody wants security" is probably not a good enough answer … Nor is "Security costs too much", especially until the costs have been more completely quantified -- including the costs of making systems that nobody will buy because they don't want to spill their guts to our friends at Meade. Even the least suspicion of pro-surveillance bias needs to be avoided for the results to be credible.

> Use of pseudonyms is applicable to very few of our protocols, and most of the ones where it
> is applicable, it is already satisfied. Anonymous use, depending on the definition one

Admittedly, the definition here is tricky. Plausible deniability only works for guilty-beyond-a-reasonable-doubt, which is missing in a number of domains. But there's a lot here we can do that we don't.

> see comments above re #1.

Ah yes, the old "if we build E2E, nobody will use it" argument. I find that to be an extremely suspicious argument, but recognize it and its kin have, for many years, led us down a rabbit-warren of bad choices, resulting in the problem we have today.

Get over it.

> not, it's not worth it. see comment above re #3.

respectfully, either you're playing for the other team, your value-system is inconsistent with mine (and consistent with that of a surveillance state), or both.

If surveillance resistance weren't more important than security, we wouldn't have TOR.

> DTN is great for the interplanetary Internet. I prefer realtime performance for almost all of my Earth-bound Internet apps. I suspect other users fell the same way. P2P is fine

But the concepts of peer-validation, explicit (rather than hidden) intermediaries, 

> I think we have generally good review for the algs we choose; we periodically review algs and key sizes and make revisions as deemed necessary. We have folks like David McGrew (Cisco) providing much of this expert review. I think we have operated in this mode for many years.

Regrettably, and as a former Cisco employee, I can tell you that folks there also face certain pressures from state actors. I'm sure this is true of most folks. David may be a saint. He might be a devil. But as an external party lacking the expertise, I have no way of telling if his position is biased against my objectives.

So unless we have widespread review, from people likely to be in the influence of multiple and conflicting actors, we really haven't had a review. How widespread? I'm not exactly sure -- but it means more than one review, from more than one company, from more than one sector, and from more than one nation-state at a minimum. Trust is really hard; our best substitute is a very widespread consensus. 

Arguably, the mode that we've operated in for many years has given us a rather bad current situation. Perhaps we should reassess "good enough".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Sep 2013 12:36:54 -0500

On Sep 10, 2013, at 1:43 PM, Hannes Tschofenig <[email-masked]> wrote:

> As you have seen my post about the VoIP stuff it is actually not so easy to say what exactly has to be done in what situations since our protocols are a bit more complex...
> 
> So, you will have to expand a bit. Maybe you also want to explain the SHOULD vs. a MUST.
> 

There's no final answer here, just a trend-reversal that points us, I think, in a batter direction.

So for example, IMAP, POP, SMTP, HTTP, SIP, RTP, all those protocols for which there is an "S" variant? Deprecate the non-S variant	 to historical ASAP. Don't write any more like them.

> That does not make sense. We are heading in the direction of everything running on 443 with TLS (from a standardization point of view) -- not necessarily on the deployment side (since otherwise we wouldn't need efforts like those from EFF).

Having only one port for everything  is information-density equivalent to having random ports, so that's acceptable.

> 
> You might also find it interesting to hear that the ability for demultiplexing HTTP 2.0 and earlier version will be done based on information in the TLS handshake and that the TLS group had decided that they prefer a solution that reveals the type of application and rejected a proposal for hiding it.

Bad decision. Question the motivations of the people who made it. Remember, we've been told that the security of our network is being systematically crippled, by design, from within. I believe that to be true, in the general (rather than specific) sense. On the other hand, maybe they just didn't think about the problem from this perspective.

> Maybe it would be worthwhile to revisit the decision?

I haven't followed the technicals; they MIGHT have good reasons. But if security/privacy/whatever really IS more important than efficiency (which Stephen has done me the honor to dispute), then a rethink is probably in order. That sounds like an IAB question that should lead to community review of fundamental principles.

> (A side remark: I was at that meeting and pointed out that this is a privacy decision and folks in the room said that this has nothing to do with privacy….

Perhaps they didn't understand. I've found that most people don't, and that much can be explained by misinformation that could also be explained by malice.

> )

> Ok. Sounds reasonable to have that option. I know that IPsec has the ability to add padding.

Again, is privacy more important than security?

> Makes sense to me (at least for protocols that are potentially run by end devices). For some protocols I guess it is less useful (thinking about routing protocols).
> 

even with routing you might want to know that a given route update came from the same source as another, even if you don't know who that source REALLY is.

> Here is the challenge: If I look at SIP then we certainly have that option but
> For example, you may not want to get interrupted with a phone call when you do not know the person on the other end.
> 

true, but there may be models where "I" know the person on the other end, but the network provider doesn't know them -- or know that I know them. That's an aspect of pseudonymity.

> I think they should have both since the functions provided are actually different.
> 
> ZRTP is not a good model if you don't know the voice of the other person. Not all communication is (a) between persons, (b) between persons who use voice communication, and (b) persons who know each other.

Other out-of-band verification models can be used. For example, if a bot's fingerprint is on its advertisement flyer, I can verify I'm communicating with the bot mentioned in the flyer rather than an impostor.

> Need to think about that.

yes, I think we all do. My opinion is that we need to internalize this position right next to the hourglass and Postel's law.

> In case of Tor we could certainly learn something about fingerprinting avoidance. I am not sure about the lessons you have learned from the other efforts. Our IETF p2p efforts are still in a dying state since the entire industry has unfortunately changed their preferred communication model in the meanwhile from p2p to client-to-server for pretty much everything.

We're in the process of distributing those servers very widely, so it'll make a comeback.

> 
> In my VoIP blog post I argued that TURN doesn't actually give you any additional privacy protection if the adversary is a powerful eavesdropper or the VoIP provider itself. It only helps when you want to hide your IP address towards the communication party, as Shida explained in his SIP privacy RFC.
> 

true. But if do something like TOR to a TURN exit, and those other factors (variable inter packet timing, variable packet sizes, random port numbers, etc.) are in place, It takes a VERY powerful attacker to correlate.

> I agree with you about the standardization aspects (regarding openness and transparency). The problem is that with the Web world we are unfortunately heading into a different direction, as we (=IAB) tried to explain some time ago with the 'post standardization' plenary (+document). I am not sure yet how to best tackle that story (and I am unfortunately not entirely alone with my lack of suggestions).
> 
> On the second suggestion I don't think you are serious. We obviously have documents co-authored by NSA employees (see http://www.arkko.com/tools/allstats/c_nsa.html) but first I dislike to exclude people (since that's the whole point of having an open standards process) and second where do you stop excluding? We have people who are contracting for the NSA, we have people who work at government organizations (like NIST), we have companies who work on government contracts (like BBN).

The reality is, we'll have people with counter-privacy secret biases doing the work, because state security apparatus fund them. Many are true believers in the missions of their apparatus.  

So there is no single trusted reviewer.

The best we can hope is large-scale consensus from multiple reviewers who hopefully have conflicting agendas. This is hard. But it's VITAL, to eliminate the taint of distrust now smeared on our systems.

Frankly, if I were a state purchasing agent outside the USA, I wouldn't want to buy systems that had been specced for me by NSA employees. But I might buy systems that had been specced by a combination of NSA, EFF, MSS, FSB, and Anonymous activists.

--
|Dean

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Sep 2013 07:49:16 -1000

> protocols

i might go further.  having some protocols in the clear allows the
attacker to better focus their efforts on what is encrypted.  also,
though some data themselves might not require privacy, the nature of
the conversation may facilitate traffic analysis.

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Sep 2013 14:18:20 -0400

> the conversation may facilitate traffic analysis.

My security concern with NTP is not so much on the encryption side as the
authentication side. Due to the nature of the protocol it is easy to get
encryption if you do authentication, so why not.

But the protocol seems to have been by the type of people who care about
synchronizing their clocks to Tier 1 stratum sources to within a nanosecond
rather than people who care about getting a very high degree of assurance
that they have a trustworthy time value that is good to maybe a minute.

I do want my system clock to be within a second of a good reference of
course. But for security purposes I would tolerate a much lower degree of
accuracy.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Sep 2013 20:12:48 +0100

Hiya,

On 09/13/2013 06:36 PM, Dean Willis wrote:
>> to hear that the ability for demultiplexing HTTP 2.0 and earlier
>> version will be done based on information in the TLS handshake and
>> that the TLS group had decided that they prefer a solution that
>> reveals the type of application and rejected a proposal for hiding
>> it.

> Bad decision. Question the motivations of the people who made it.
> Remember, we've been told that the security of our network is being
> systematically crippled, by design, from within. I believe that to be
> true, in the general (rather than specific) sense. On the other hand,
> maybe they just didn't think about the problem from this
> perspective.

On this point: I think we're actually ok.

The TLS WG were asked to provide this feature for HTTP/2.0.
One proposal involved establishing confidentiality before
nominating the next protocol, but was somewhat hacky in how
it fit into TLS1.2. The other (ALPN) was selected as it did
the job required for HTTP/2.0 more cleanly.

BUT, the WG also decided (formally I guess a little later on)
to start work on TLS1.3 with a major goal of that work being
to confidentiality protect much more of the TLS handshake as
an inherent protocol feature. And that work has started,
though I don't think there's an I-D just yet.

So the TLS WG decision was in fact to go for more
confidentiality.

FWIW I think that was the right choice,

S.

---

From: SM <[email-masked]>
Date: Sat, 14 Sep 2013 06:55:40 -0700

Hi Dean,
At 10:12 13-09-2013, Dean Willis wrote:
>So unless we have widespread review, from people likely to be in the 
>influence of multiple and conflicting actors, we really haven't had 
>a review. How widespread? I'm not exactly sure -- but it means more 
>than one review, from more than one company, from more than one 
>sector, and from more than one nation-state at a minimum. Trust is 
>really hard; our best substitute is a very widespread consensus.
>
>Arguably, the mode that we've operated in for many years has given 
>us a rather bad current situation. Perhaps we should reassess "good enough".

The IETF has been operating in "good enough" mode since a long 
time.  Some proposals do not get widespread review.  There are 
variations of RFC 6302 in the IETF RFCs.  When I raised a "privacy 
issue" some time back the only person who supported the argument was 
Stephen Farrell.  The amount of effort to raise a "privacy issue" is 
discouraging.

It's difficult to ensure review from more than one nation-state when 
the majority is from one nation-state.  It is not always clear what 
the company or sector ties are.

There is a report of a Tor exit node being compromised.  It's 
unlikely that the problem could have been avoided with better 
encryption.  The architectural aspect of the problem was mentioned in 2005.

Regards,
-sm

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 14 Sep 2013 17:54:43 +0000

SM:
>> influence of multiple and conflicting actors, we really haven't had a
>> review. How widespread? I'm not exactly sure -- but it means more than
>> one review, from more than one company, from more than one sector, and
>> from more than one nation-state at a minimum. Trust is really hard;
>> our best substitute is a very widespread consensus.
>>
>> Arguably, the mode that we've operated in for many years has given us
>> a rather bad current situation. Perhaps we should reassess "good enough".
> 
> The IETF has been operating in "good enough" mode since a long time. 
> Some proposals do not get widespread review.  There are variations of
> RFC 6302 in the IETF RFCs.  When I raised a "privacy issue" some time
> back the only person who supported the argument was Stephen Farrell. 
> The amount of effort to raise a "privacy issue" is discouraging.
> 

Seems like that isn't a problem now, right? Water under the bridge,
perhaps? I have also seen a lot of IETF privacy and security weirdness
but it is clear that things are improving now.

> It's difficult to ensure review from more than one nation-state when the
> majority is from one nation-state.  It is not always clear what the
> company or sector ties are.

I don't think that this is a problem at all. I see people from a dozen
countries on this list.

> 
> There is a report of a Tor exit node being compromised.  It's unlikely
> that the problem could have been avoided with better encryption.  The
> architectural aspect of the problem was mentioned in 2005.
> 

(Tor Developer here...)

What are you referring to with regard to a Tor exit node being compromised?

All the best,
Jacob

---

From: Norbert Bollow <[email-masked]>
Date: Sat, 14 Sep 2013 21:06:55 +0200

Jacob Appelbaum <[email-masked]> wrote:
> > issue" some time back the only person who supported the argument
> > was Stephen Farrell. The amount of effort to raise a "privacy
> > issue" is discouraging.
> > 
> 

At some point in the future it will be good to do some kind of post
mortem analysis to figure out how it happened that things went so badly
off track in regard to privacy protection.

But I agree, the Snowden disclosures definitely mark a turning point.

Privacy concerns are going to get taken serious now.

Greetings,
Norbert

---

From: SM <[email-masked]>
Date: Sat, 14 Sep 2013 12:36:11 -0700

Hi Jacob,
>but it is clear that things are improving now.

I already commented about the problem on the relevant list.  There 
was an interesting message from Yoav Nir ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg82383.html ).  I 
don't know whether things are improving.

>I don't think that this is a problem at all. I see people from a dozen

I commented on two drafts this week (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg82438.html and 
http://www.ietf.org/mail-archive/web/ietf/current/msg82466.html ).

I posted the following last year 
http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00230.html

>What are you referring to with regard to a Tor exit node being compromised?

I'll comment off-list.

Regards,
-sm

---

From: Phil Karn <[email-masked]>
Date: Fri, 20 Sep 2013 07:49:39 -0700

> the conversation may facilitate traffic analysis.

Yes. We've seen indications that the NSA stores all encrypted traffic
for a rainy day, so the more chaff we can generate the sooner the NSA
will have to look for new real estate in Utah.

--Phil