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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
