Re: [perpass] Howdy!

Rene Struik <rstruik.ext@gmail.com> Fri, 06 September 2013 20:40 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C4C11E80F7 for <perpass@ietfa.amsl.com>; Fri, 6 Sep 2013 13:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWVUehhY4gEL for <perpass@ietfa.amsl.com>; Fri, 6 Sep 2013 13:40:50 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id F193311E80F4 for <perpass@ietf.org>; Fri, 6 Sep 2013 13:40:48 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id tp5so8172658ieb.0 for <perpass@ietf.org>; Fri, 06 Sep 2013 13:40:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EBS9famQb2r/uxCK4348jPM6aeNrCVjIJYK21qo2TWQ=; b=Y2Pnn+m3JD756dvJ2HuHj2L+QYG4AX1hnlyYl2PfV2eqN73GvR4N1HhEHbwn+Tj4Ar aCrU9K1epAv3FpUKEOO6olMHYr0WF9dotCV/ETobVkOj/cP63lwEeKGB3Atn/F/aCSlG EekN84VpMcH4c1zqMglX0apNtZBid6PoAh5w3a9wSC1pJDnCl+nikMuzbH1OBfxl6rxz UB7H9PUcfzDZSYcMXbkVwLRhr+XBZi5sw9ZRBg1k/htu3bdqaYFQSuvaTo2stZV9fAIH lKFTq1VGQL3XLbx2CboJ+4Dv1lTbcg+rq+jmjLnlBXmyDxydzoDQPGda15dNhX4hdByG K96Q==
X-Received: by 10.42.26.73 with SMTP id e9mr2711473icc.40.1378500047704; Fri, 06 Sep 2013 13:40:47 -0700 (PDT)
Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPSA id ka5sm253250igb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 13:40:47 -0700 (PDT)
Message-ID: <522A3DC1.6010901@gmail.com>
Date: Fri, 06 Sep 2013 16:40:33 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CAOHm=4ujOYTHO63EFWMYJBgxUWq00zezYKAJ8B4Vgf_C=xRRVg@mail.gmail.com> <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie>
In-Reply-To: <522A328A.5060008@cs.tcd.ie>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org, Dean Willis <dean.willis@softarmor.com>
Subject: Re: [perpass] Howdy!
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2013 20:40:51 -0000

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

On 9/6/2013 3:52 PM, Stephen Farrell wrote:
> 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.
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
>>
>> 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.
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
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363