Re: [perpass] Howdy!

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: perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, September 06, 2013 3:53 PM
To: Dean Willis
Cc: perpass@ietf.org
Subject: Re: [perpass] Howdy!

Hi Dean,

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

Others opinions?

S.

On 09/06/2013 02:23 AM, Dean Willis wrote:
> 
> On Sep 2, 2013, at 1:55 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
>>
>> 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.
>>
> 
> 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
> 
> 
> 
> 
> 
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass