OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [kmip] KMIP: RNG Proposals

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. 


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


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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]