Re: [Cfrg] considering new topics for CFRG

Paul Lambert <paul@marvell.com> Tue, 07 January 2014 00:46 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 31E271AE2BF for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 16:46:43 -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 fkncsny3I2FQ for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 16:46:40 -0800 (PST)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id B8ED41ADBC9 for <cfrg@irtf.org>; Mon, 6 Jan 2014 16:46:40 -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 s070kTXZ020839; Mon, 6 Jan 2014 16:46:29 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1h5qbueutg-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 06 Jan 2014 16:46:29 -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 16:46:28 -0800
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 6 Jan 2014 16:46:27 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8LM7gonDptIzDhR9+BTyVpg1yJAAAATO7w
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E173@SC-VEXCH2.marvell.com>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com> <52C9F739.1020301@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com> <CACsn0cmBFwQ3bxpNd1fNaPWAqsEtgXe7fdTSOz2npbSAEYYVwA@mail.gmail.com>
In-Reply-To: <CACsn0cmBFwQ3bxpNd1fNaPWAqsEtgXe7fdTSOz2npbSAEYYVwA@mail.gmail.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="utf-8"
Content-Transfer-Encoding: base64
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_05:2014-01-07, 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-1401060184
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: Tue, 07 Jan 2014 00:46:43 -0000


> From: Watson Ladd [mailto:watsonbladd@gmail.com]
> Sent: Monday, January 06, 2014 3:05 PM
> To: Paul Lambert
> Cc: David McGrew; Sean Turner; cfrg@irtf.org
> Subject: Re: [Cfrg] considering new topics for CFRG
>
> 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?
Possible - but it's more complexity and bits to send.
Also - I'm not asking for roles ... which might in a more complex
authorization model support a large number of keys and associated roles/attributes.

Given a public key, we have arbitrary limitations that declare that
signatures MUST use one key and encryption must use another.

>
> 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.
There are proposed uses of Ed25519.

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

This tends to be one of the problems with modern crypto.
Easy proofs may not make the best overall system design.

Many 'key usage guidelines' also mandate different keys because of
different lifetime and usage models of encryption versus signatures.
Specifically - the guidelines say that encryption keys must be different
so the encryption keys can be escrowed.  Signature keys do not need escrow.

This and many other guidelines indicate an inherent double standard
where signatures are good for mass deployment, but encryption must
be handled differently.

One public key should be able to do the suite of necessary
operations.  Specifically - signatures and pair-wise key establishment.

Mechanisms exist - but industry or NIST 'approval' of this architecture is lacking.

> 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?
Yes - they are possible ... but the overall requirement is
dispel any mistrust.   Curve25519 is relatively new and this group
could help review/bless/approve it's usage.  Academic papers
do not cut it for industry application. NIST, IETF or other
industry groups need to make clear recommendations with
transparent justifications.

> >
> > 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.
Longer debate possible ... but this was just one approach to
demonstrating the provenance of a selected number.

> We don't need seeds to pick good curves: just some MAGMA scripts (or
> PARI, or SAGE).
Perhaps ... but recently I've seen considerable debate about
about NIST curves and the seed selection not being well documented.

Seems easy to fix the provenance issue by re-selecting parameters.

> DJB and Paulo Barrato have already done this: I don't see CFRG as
> having a comparative advantage in this area.
Perhaps ... but adoption in real products requires some level
of documented review and acceptance.  The CFRG could provide
a basic set of recommendations that would mitigate concerns
about 'special numbers' being injected into the standar.

>
> >
> > 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.
I am not suggesting that it is the only heuristic.  This is for whatever reasons
a type of operation that is widely avoided in real systems.

CCM and GCM are nonce sensitive partly for this one-to-one bit stream
cipher mapping.

> 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?
Wide-block PRP is interesting.  I need to spend more time looking at AERO.

>
> >>
> >> >   - 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.
I'm currently working on the last three above in other forums.
They could be separate topics, but if you consider addresses to
Be ephemeral than it changes the way you look at authentication.


> 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.
Never mentioned multi-party.  It has been used in more than your named example.

> 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.
Great.
We need to prune the tree of algorithms to enable new ones to florish.


Paul


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