[Cfrg] considering new topics for CFRG

David McGrew <mcgrew@cisco.com> Sat, 04 January 2014 00:47 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B85C11AE014 for <cfrg@ietfa.amsl.com>; Fri, 3 Jan 2014 16:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.039
X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rXG9GaqEL5Z0 for <cfrg@ietfa.amsl.com>; Fri, 3 Jan 2014 16:47:00 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 543171AD8C4 for <cfrg@irtf.org>; Fri, 3 Jan 2014 16:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4667; q=dns/txt; s=iport; t=1388796413; x=1390006013; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=MdlNy5F/rItqTcEbk8zhXGs3eBEO1D6Hb8UryZp+6FA=; b=ZHYK+FVpbUNgcxfMMdDjF2nhPlkLes+7ktVuhqDt96Dy7tV8jwQLlpea LhANfI3RXGzs4Hy4vbe1zQJ7HdzPVfWSOM59/HhsOhpKpJaAh3p+vXA9X tsSw4xg2lqs4/R4svE/S6SxziiILI0AksYZVuSCVTZJyKH8czEPvxRSMQ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.95,601,1384300800"; d="scan'208";a="295184517"
Received: from rcdn-core2-4.cisco.com ([]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jan 2014 00:46:51 +0000
Received: from [] (rtp-mcgrew-8913.cisco.com []) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s040komr003958; Sat, 4 Jan 2014 00:46:50 GMT
Message-ID: <52C755AA.70200@cisco.com>
Date: Fri, 03 Jan 2014 19:28:26 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Sean Turner <turners@ieca.com>
Subject: [Cfrg] considering new topics for CFRG
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jan 2014 00:47:02 -0000


recently, Stephen and others suggested some topics that seem worth 
considering as future work for this research group.   I want to expand 
on those suggestions, and solicit your input.  If there is sufficiently 
broad interest, and people willing to contribute, than we can consider 
taking it on.   The goal of this note is to gauge interest in some 
topics that I have heard others talk about, and some that I think are 
worthwhile.  Recall that CFRG is a bridge between theory and practice, 
and traffic can go in both directions. The practice community can 
identify unsolved problems and new issues that aren't dealt with in 
theory.   Conversely, the theory community can introduce new results.

Stephen, Sean, please do let us know what work would be most useful to 
the IETF Security Area, and what work would be less useful or would 
conflict with IETF chartered work.   Thanks!

Useful topics on side channel attacks:

- Documenting ways of implementing existing algorithms that resist 
side-channel attacks, especially timing attacks.   This could include 
documentation of naive implementation methods that are vulnerable, or 
experimental work quantifying vulnerabilities.

- The development of testing methodologies for crypto implementations 
that can identify vulnerabilities to side-channel attacks.  A test 
harness that runs in separate software or hardware that interacts with a 
target crypto implementation could collect timing statistics, which 
could then be analyzed to check for vulnerabilities.   There are crypto 
module validation schemes such as CMVP that are widely used.   Why don't 
we develop a testing methodology for such schemes that would identify 
timing vulnerabilities?

- The design, identification, and/or specification of algorithms that 
resist side channel attacks.

- The design, identification, and/or specification of algorithms that 
lack subliminal channels; that is, algorithms that would be hard to 
implement in a way that subverted the privacy of the user without their 
knowledge.   Also interesting would be testing methodologies that detect 
such channels, possibly including static analysis of source code, or 
statistical analysis of random or pseudorandom sources.

Useful topics in crypto algorithm design:

- Authenticated encryption that does not require an application to 
manage nonces and/or is robust against nonce misuse.

- Simplicity of design as a way to achieve robust crypto implementations.

- Recommendations on algorithms that should be used.   This could 
include recommendations on DRBGs.

Useful topics in provable security:

- A document describing the hierarchy of goals for security proofs, and 
recommendations on what IETF WG expectations should be regarding such 
proofs.   It would also be useful to describe the important security 
models, and to provide referenceable common definitions.

- Provably secure designs for complex protocols.   For instance: can 
there be a provably secure protocol that provides the same level of 
critical functionality as TLS, yet at the same time has been proven 
secure using techniques and/or tools that are accessible to many reviewers?

Useful topics in privacy

- Analyzing and documenting the limitations on privacy/anonymity 
technologies in the Internet protocols.   For example: if your MAC 
address and/or IPv6 address are traceable, then cryptography is not 
going to get you strong anonymity, no matter what crypto you use. 
Additionally, analysis of packet lengths and timings can reveal a lot of 
information.   Existing IETF security protocols have message-length 
hiding mechanisms, but these are not very effective.   If we are wiling 
to add latency and consume extra bandwidth, we could improve security in 
this area.   Is it worth it?

No doubt this is not an exhaustive list, and if you have other topics to 
put forward, please send them to the list and keep "considering new 
topics" in the subject line to make it easier to keep track.

One topic that I didn't list above, because it is somewhat outside of 
CFRG's traditional scope, is security in Cloud environments.  To my 
thinking, the industry trend towards putting all the data one can get a 
hold of into multi-tenant, virtualized environments is one of the 
biggest threats to information security and privacy.   Maybe I trust the 
Cloud provider to be well intentioned, but can I actually trust them to 
maintain data security?    I didn't try to craft a topic along this line 
because it goes beyond the scope of communication security.