[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [173.37.86.77]) 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-Anti-Spam-Result: AgUFAJNZx1KtJXG//2dsb2JhbABOCoMLujOBDBZ0gmRBPDQCTA0BBwIQh3DDRxeOMlyEPgSJQ45UhkWLT4NLHoEuJA
X-IronPort-AV: E=Sophos;i="4.95,601,1384300800"; d="scan'208";a="295184517"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jan 2014 00:46:51 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8913.cisco.com [10.117.10.228]) 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
Hi, 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. regards, David
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Trevor Perrin
- [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG David Wagner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Adam Back
- [Cfrg] QKD is pointless (was: Re: considering new… David McGrew
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paterson, Kenny
- Re: [Cfrg] QKD is pointless (was: Re: considering… Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Watson Ladd
- [Cfrg] DANE in the IETF (was: Re: considering new… Paul Hoffman
- [Cfrg] One Key -> RE: considering new topics for … Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paul Lambert
- [Cfrg] ReL DANE in the IETF (was: Re: considering… Paul Hoffman
- Re: [Cfrg] QKD is pointless David McGrew
- Re: [Cfrg] QKD is pointless Hilarie Orman
- [Cfrg] likelihood that someone has a quantum comp… David McGrew
- Re: [Cfrg] considering new topics for CFRG dan
- Re: [Cfrg] likelihood that someone has a quantum … David Jacobson
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … Watson Ladd
- Re: [Cfrg] likelihood that someone has a quantum … Yoav Nir
- Re: [Cfrg] likelihood that someone has a quantum … Stephen Farrell
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] likelihood that someone has a quantum … Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless David Wagner
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Igoe, Kevin M.
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- [Cfrg] 'key centric' architecture (was: Re: consi… Rene Struik
- Re: [Cfrg] 'key centric' architecture (was: Re: c… Richard Barnes
- Re: [Cfrg] considering new topics for CFRG David McGrew