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, 4 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