Re: [Cfrg] considering new topics for CFRG

[Watson Ladd <[e-mail]>]

On Mon, Jan 6, 2014 at 12:32 PM, Paul Lambert <[e-mail]> wrote:
>
>
>> -----Original Message-----
>> From: David McGrew [mailto:[e-mail]]
>> > 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" <[e-mail]> 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
>> >> [e-mail]
>> >> http://www.irtf.org/mailman/listinfo/cfrg
>> > .
>> >
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> 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