Re: [Cfrg] considering new topics for CFRG

Paul Lambert <> Sat, 04 January 2014 11:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0C0D51ADE8B for <>; Sat, 4 Jan 2014 03:20:52 -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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JBYGDJBIbZlH for <>; Sat, 4 Jan 2014 03:20:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 89D061ADD9D for <>; Sat, 4 Jan 2014 03:20:50 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s04BKe4Y001640; Sat, 4 Jan 2014 03:20:40 -0800
Received: from ([]) by 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 ([]) by ([]) with mapi; Sat, 4 Jan 2014 03:20:37 -0800
From: Paul Lambert <>
To: David McGrew <>, "" <>
Date: Sat, 04 Jan 2014 03:20:36 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8JPv1rE8nF6jpQTNmsGtEZTlZ5ng==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
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 <>
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 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)


On 1/3/14, 4:28 PM, "David McGrew" <> wrote:

>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
>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.
>Cfrg mailing list