Re: [Cfrg] considering new topics for CFRG

Paul Lambert <paul@marvell.com> Mon, 06 January 2014 20:33 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 6E41C1AE1CB for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 12:33:02 -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 0on1wEaFkyj8 for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 12:33:00 -0800 (PST)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5CADF1AE1AD for <cfrg@irtf.org>; Mon, 6 Jan 2014 12:33:00 -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 s06KWnoi007069; Mon, 6 Jan 2014 12:32:49 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1h5qbue0ue-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 06 Jan 2014 12:32:49 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 6 Jan 2014 12:32:49 -0800
From: Paul Lambert <paul@marvell.com>
To: David McGrew <mcgrew@cisco.com>
Date: Mon, 6 Jan 2014 12:32:48 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8KdV0A4GQJtQamQ9mjafIg74trzwApkXTw
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com> <52C9F739.1020301@cisco.com>
In-Reply-To: <52C9F739.1020301@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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-06_03:2014-01-06, 2014-01-06, 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-1401060136
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 20:33:02 -0000

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

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

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

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

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

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