RE: [kmip] KMIP: RNG Proposals

[Chuck White <cwhite@semper-fortis.com>]

Howdy everyone!

IMHO, we should leave the decision to use something deprecated (in terms of RNG algorithms) to folks who integrate solutions that utilize KMIP.

One thought from a Systems Engineering perspective, we should be careful not to remove capability (ie deprecated RNG algorithms).

Given that KMIP is effectively a "data contract" for utilizing, managing, and distributing encryption keys,  I think it is better not to take anything away.  This also has added benefit in helping those who adopt KMIP in the future to have a capacity for transition if they are currently using deprecated RNG algorithms.  In other words, let KMIP be a bridge to better security vs a barrier to getting there. 

The downside is that you are giving folks enough rope to hang themselves in terms of enabling use of algorithms that compromise security. 
 
Thanks!

Chuck 

-----Original Message-----
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Mike Yoder
Sent: Monday, December 16, 2013 2:39 AM
To: Robinson, Peter (RSA Engineering); Tim Hudson; kmip@lists.oasis-open.org
Subject: RE: [kmip] KMIP: RNG Proposals

> 
> >NIST SP 800-90 Dual EC DRBG.
> There are some people who use this algorithm. As such, I don't think 
> removing it outright is the correct thing to do.

Fair enough.  There is a reasonable argument that says that even the "undesirable" algorithms should have a place, just so the client knows exactly what they're in for.

> > DES.... Well... maybe we ought to remove (or at least deprecate) 
> > those, too.  Why include anything that is known insecure?  Shouldn't
> we, as a
> > group, feel qualified to make a value judgment here?  Or at least
> follow NIST guidance?
> 
> Deprecating the use of algorithms seems like a good idea, but where do 
> we draw the line? Should we do this based on security strength?

A first pass would be to just copy NIST's 800-131a document, which is your deprecated list.

> For example we could say:
> 
> Deprecated: Less than or equal to 80 bits of security strength: DES, 
> RC2, MD2, MD4, MD5, Dual EC DRBG, FIPS 186 PRNG and RSA for key sizes 
> less than or equal to 1024, EC with P160 curve.

And by this you mean that the algorithms would still be selectable, but noted in the standard as being deprecated, I assume?

> Deprecated for use in new applications: Between 80 and 112 bits of 
> security strength: 3DES, SHA 224, RSA 2048, EC with P224 curve.

Hmmm.  I would be on board with this in theory, but putting RSA 2048 on that list basically requires a transition to EC to go higher given the performance of RSA 4096.  A good thing, but rather bold.  It might be considered overreach.


John Leiseboer wrote:
> Indeed, where do we draw the line? One client's secure algorithm is 
> another client's insecure algorithm. Make recommendations. Provide 
> guidance. Do not introduce weaknesses, and vulnerabilities into the 
> standard. Build ease of use into the standard; i.e. be secure by 
> default, and force clients to explicitly change the default, or 
> standard way of doing things, in order to be insecure.

I agree with this.  But...for the sake of argument let's take an extreme case - DES. Crackable in under 24 hours at cloudcracker (MS-CHAPv2) for something like $17.  Should we allow clients to impale themselves upon it?

Thinking back on this, (and contradicting my previous paragraph) I realize that I'm coming at this argument from a user interface point of view, where simplicity and removing everything that's not needed are good things.  But perhaps this isn't the way to go for a standard such as KMIP, where we've got to support a wide variety of behaviors amongst clients / servers.  This means we have to leave everything in, but we can at least provide guidance...

-Mike


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php