Re: [Cfrg] considering new topics for CFRG

David McGrew <mcgrew@cisco.com> Mon, 06 January 2014 00:22 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 3B6021AD9B8 for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 16:22:29 -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 3FQde5uFWsID for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 16:22:27 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D2B181AD9B7 for <cfrg@irtf.org>; Sun, 5 Jan 2014 16:22:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7022; q=dns/txt; s=iport; t=1388967739; x=1390177339; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yo/dh22Qyak+nSwSzEwM/vdsHL39uUF1vU3m7QUUR9A=; b=iCNQffHdUyKrtHlD2V+FoxKw9puhgNcCTpC/W5C+OaKd+bfKS1l53wyI nkY2hJcaMyRlBzdn5kJ+M3xoMwAf+drXNzDnTmuK0hpEeYF9rR4Q7xnM7 6Y3LJ+GA3oxyOKiPQRXSKpiomzcEeTdzxXWvfWHZjxuKzvrNq4u2WjSFG M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAOT2yVKtJXG//2dsb2JhbABOCoMLOLoFgQ0WdIIlAQEBAwEBAQEkCwEFNgoBBQsLEgYJFg8JAwIBAgEVIg4GDQEFAgIFC4doCA3DLBeMbYFGXAeENwSJQ45UhkWLUINLHoEuJA
X-IronPort-AV: E=Sophos;i="4.95,609,1384300800"; d="scan'208";a="295394653"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jan 2014 00:22:18 +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 s060MHjQ012276; Mon, 6 Jan 2014 00:22:17 GMT
Message-ID: <52C9F739.1020301@cisco.com>
Date: Sun, 05 Jan 2014 19:22:17 -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: Paul Lambert <paul@marvell.com>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com>
In-Reply-To: <CEED2882.2B867%paul@marvell.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Sean Turner <turners@ieca.com>, "cfrg@irtf.org" <cfrg@irtf.org>
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: Mon, 06 Jan 2014 00:22:29 -0000

Hi Paul,

thanks for your suggestions.

On 01/04/2014 06:20 AM, Paul Lambert wrote:
>
> My wish list for 2014:
>
>   - A public key based ¹trust¹ architecture to
>     determine ³who can do what² (not based on X.509 or PGP)

This is an intriguing thought, but probably something out of scope for 
CFRG.   (Seems more like a PKNG thing if I understand you right.)

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

I'm with you on that one.

>   - Elliptic curves for cryptographic use that are developed
>     in a transparent manner that dispels any possible mistrust

Yes, this is a good one.  I think there is sufficient interest in this 
topic in the IETF to warrant this work.

>   - Algorithm modes that have infinite error extension
>     (verus CCM, 1 bit plaintext change -> 1 bit ciphertext)

This seems in scope.

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

Would be interesting.   Probably not in our RG scope, I would guess.

>   - Deprecation and abolishment of known bad algorithms:
>     in a manner that impacts real products
>     (e.g. TKIP, WEP, DES, RC4)
>

CFRG can't initiate the standards that deprecate algorithms, but there 
are probably things that we can do to hilight the need for that 
deprecation (in practice as well as in standards).   One thing I'd like 
to see is the cipher-catalog get completed, with some clear guidance in 
it on what is recommended and what is not.   It would be great to see 
that RFC get referenced in open source, for example.

David


> 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
> .
>