Re: [Cfrg] considering new topics for CFRG
Paul Lambert <paul@marvell.com> Sat, 04 January 2014 11:20 UTC
Return-Path: <paul@marvell.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 0C0D51ADE8B for <cfrg@ietfa.amsl.com>; Sat, 4 Jan 2014 03:20:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
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 JBYGDJBIbZlH for <cfrg@ietfa.amsl.com>; Sat, 4 Jan 2014 03:20:50 -0800 (PST)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 89D061ADD9D for <cfrg@irtf.org>; Sat, 4 Jan 2014 03:20:50 -0800 (PST)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s04BKe4Y001640; Sat, 4 Jan 2014 03:20:40 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1h5qbu4mkn-15 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 04 Jan 2014 03:20:40 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Sat, 4 Jan 2014 03:20:37 -0800
From: Paul Lambert <paul@marvell.com>
To: David McGrew <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Sat, 04 Jan 2014 03:20:36 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8JPv1rE8nF6jpQTNmsGtEZTlZ5ng==
Message-ID: <CEED2882.2B867%paul@marvell.com>
References: <52C755AA.70200@cisco.com>
In-Reply-To: <52C755AA.70200@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-04_01:2014-01-03, 2014-01-04, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401040034
Cc: Sean Turner <turners@ieca.com>
Subject: Re: [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 11:20:52 -0000
My wish list for 2014: - A public key based ¹trust¹ architecture to determine ³who can do what² (not based on X.509 or PGP) - Public key based methods that can be readily be used to both sign data and be used to develop encryption keys - Nonce insensitive or deterministic encryption modes to support group multicast in a mesh topology - Elliptic curves for cryptographic use that are developed in a transparent manner that dispels any possible mistrust - Algorithm modes that have infinite error extension (verus CCM, 1 bit plaintext change -> 1 bit ciphertext) - Secure time stamps - A 'setup process' based on public keys to enable the secure configuration of consumer products - Strong P2P authentication for Wi-Fi devices - Ephemeral MAC Addresses - Deprecation and abolishment of known bad algorithms: in a manner that impacts real products (e.g. TKIP, WEP, DES, RC4) Paul On 1/3/14, 4:28 PM, "David McGrew" <mcgrew@cisco.com> wrote: >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 >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg
- 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