Re: [Cfrg] considering new topics for CFRG
Watson Ladd <watsonbladd@gmail.com> Mon, 06 January 2014 23:05 UTC
Return-Path: <watsonbladd@gmail.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 4385C1AE2C8 for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 15:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 10Xb_Yes9BaV for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 15:05:04 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D8F471AE2C6 for <cfrg@irtf.org>; Mon, 6 Jan 2014 15:05:03 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so16138601wgh.13 for <cfrg@irtf.org>; Mon, 06 Jan 2014 15:04:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BS+H86wF/tYFl2ltRdxy49obiMw5vrYnAqFEAV5b2SY=; b=cV6GaYz9v903FMp7efBCsOiEIdy25+A3gBAkbVkVH0mr3+k/qV1cacszkBUQVcUPvW xMSobj6XmAnM2NNcymZ3mvwOpbtJple/ggDGCx5cAQdwz4CWOKcPRlRTes6kAW+pPGex TYsy1uINHYuTj5ccCX0rkNzHLkNr7vXwbnaaD3EO/GaEOGDmo1RfztDUkZl5qHRp0eI5 KhI6vf+vAEO2Tr6t81Si8izMH830+ZirFo3yNaU//T32OLwAIHAJtDi9AFLKFsnugMim gezEHFS8nw7XsrhyIjBKPS080sQNwvSyCltgxDGxlgnl5V8FxPCz2NyTfrHZk0UsTQac 1MYQ==
MIME-Version: 1.0
X-Received: by 10.180.149.175 with SMTP id ub15mr14387364wib.44.1389049494578; Mon, 06 Jan 2014 15:04:54 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 6 Jan 2014 15:04:54 -0800 (PST)
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com> <52C9F739.1020301@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com>
Date: Mon, 06 Jan 2014 15:04:54 -0800
Message-ID: <CACsn0cmBFwQ3bxpNd1fNaPWAqsEtgXe7fdTSOz2npbSAEYYVwA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Sean Turner <turners@ieca.com>, David McGrew <mcgrew@cisco.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 23:05:07 -0000
On Mon, Jan 6, 2014 at 12:32 PM, Paul Lambert <paul@marvell.com> wrote: > > >> -----Original Message----- >> From: David McGrew [mailto:mcgrew@cisco.com] >> > 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.) > > There was an IETF PKNG that died with no visible results. > This is an area where the IETF seems either too unfocused or mired > in existing PKI to make progress. Hence it's on my wish list ... > Let me know if you have any suggestion for other viable forums in IETF > for such a topic. > >> > - 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. > This came out of my personal requirements for the above framework. > Having a public key for encryption versus one for signing greatly > complicated our frameworks for security. Why not have the primary master signing key sign individual keys for each role? This is an interesting problem, but one that is quite nasty: you need to show that solving a problem with access to some oracles is still reducible to a hard problem. For some commonly deployed schemes (RSA, I'm looking at you) this separation is necessary. Public key encryption isn't actually necessary: hybrid encryption is much, much nicer to live with and implement. Look up the history of OAEP for a reminder of just how tough it is. By contrast if RSA based key agreement is needed, H(C, P) for ciphertext C and plaintext P does an excellent job. Look ma, no padding! In the ROM I think you can show that exposing that oracle doesn't hurt the security of signing, but I can't remember what exactly RSA signing looks like. I do DH based schemes almost exclusively. The reason we use one key for each job is it makes life easy in the land of proofs: everything composes. The instant things become dependent on each other, life gets unfun. > >> >> > - 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. > This could be addressed quite quickly by simply regenerating seed values > for a few of the small Weistrass based curves. What is wrong with Curve25519 or the bigger variants? > > I'd suggest that we could define a seed entropy process that would allow > multiple individuals/groups to contribute seed values that would be combined > in a three phase process. Phase 1 - send a Commit > commit_i = h(nonce_i, seed_i) > After some deadline, Phase 2 - send Reveal > Reveal_i = nonce_i, seed_i > > Phase 3 - combine submitted seeds. > def seed(seed_list): > hash = h() > for s in seed_list: > hash.update(s) > return hash.digest() As has been pointed ad nauseam, this only works if you are one of the seed producers. We don't need seeds to pick good curves: just some MAGMA scripts (or PARI, or SAGE). DJB and Paulo Barrato have already done this: I don't see CFRG as having a comparative advantage in this area. > > A distributed community based process for creating trusted random values would be valueable. > >> >> > - Algorithm modes that have infinite error extension >> > (verus CCM, 1 bit plaintext change -> 1 bit ciphertext) >> >> This seems in scope. I really don't like this at all. Error extension has a terrible history of being used as a heuristic for the security of protocols that were later busted wide open, because attackers are smart. Infinite-garble extension in Kerberos is the example that comes to mind. There is a notion of wide-block PRP that actually does what you are looking for, I think. AERO relies on that. Yes, it's inefficient, but it exists. What sort of requirement do you want this new mode to meet, and why should we care about meeting it? What gains does it get over existing modes and notions of security? >> >> > - 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. > Yes ... unfortunately. The actual application of crypto in protocols > is generally more interesting and useful than raw math functions (IMO :-). > Applications also creates new requirements for algorithms and their usage I would actually like this to be in scope. If we can discuss what the commercial needs are that current solutions aren't meeting, we have a chance at drumming up interest in good solutions. Although I feel that hardwired configuration ports are usually decent enough for the specific case mentioned by grandparent. Most applications require secure point to point communication with authentication. Multiparty computation has been used exactly once in the real world, namely for a sugar beet auction on an island in Denmark. I don't really see new requirements on core algorithms coming from the sort of people who care about the I(E|R)TF standardization status of whatever they use. >> >> > - 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. > A catalog with very clear and strong recommendations would help solve this problem. I think this is an excellent idea. Time for me to put in some grunt work. > > Paul > >> >> 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 >> > . >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- 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