Re: [Cfrg] considering new topics for CFRG

Sean Turner <> Sat, 04 January 2014 01:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7BB781AE032 for <>; Fri, 3 Jan 2014 17:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Efz2dmp_BXlT for <>; Fri, 3 Jan 2014 17:44:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C8A701AE02C for <>; Fri, 3 Jan 2014 17:44:08 -0800 (PST)
Received: by (Postfix, from userid 5007) id 25C57516DB1B4; Fri, 3 Jan 2014 19:44:01 -0600 (CST)
Received: from ( []) by (Postfix) with ESMTP id 057F0516DB18D for <>; Fri, 3 Jan 2014 19:44:01 -0600 (CST)
Received: from [] (port=62295 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <>) id 1VzGHQ-0002iA-BX; Fri, 03 Jan 2014 19:44:00 -0600
Content-Type: multipart/signed; boundary="Apple-Mail=_754C923D-9835-459F-B175-34B270A6B267"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Sean Turner <>
In-Reply-To: <>
Date: Fri, 03 Jan 2014 20:43:57 -0500
Message-Id: <>
References: <>
To: David McGrew <>
X-Mailer: Apple Mail (2.1827)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: ([]) []:62295
X-Email-Count: 5
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Cc: "" <>
Subject: Re: [Cfrg] considering new topics for CFRG
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Jan 2014 01:44:10 -0000


I’ve got some thoughts about the process question that I’ll put in another email to not muddy up the more interesting technical thread.


On Jan 03, 2014, at 19:28, David McGrew <> 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