RE: [kmip] KMIP: RNG Proposals

[John Leiseboer <JL@quintessencelabs.com>]

> Deprecating the use of algorithms seems like a good idea, but where
> do we draw the line? Should we do this based on security
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.

Algorithm selection is best left to the client, or the server policy/configuration manager. Supporting "insecure" algorithms does not necessarily mean insecure operation will result. Same as limiting support to only "secure" algorithms does not mean secure operation will result.

John

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


>Prediction Resistance from NIST SP 800-90.
My reason for requesting inclusion of this is that we have some customers using PRNGs with Prediction Resistance ON. If we are going to return information about the PRNGs in use, then this is an important parameter for those customers.


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


> 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? That is, anything with a security strength of 80 bits of less should be deprecated. Should we also advise anything with a security strength of 112 bits of less shouldn't be used in a new application (assuming your new application is going to stay in use post 2030 when 112 bit security strength is expected to be breakable)? 

Who feels confident assigning security strengths to all algorithms?

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. 

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


Peter
------------------------------------------------
Peter Robinson - peter.robinson@rsa.com
Senior Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 11, Central Plaza One, 345 Queen Street, Brisbane, Queensland 4000, AUSTRALIA.
Phone: +61 7 3032 5253, Mobile: +61 407 962 150. 


-----Original Message-----
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Mike Yoder
Sent: Saturday, 14 December 2013 11:15 AM
To: Tim Hudson; kmip@lists.oasis-open.org
Subject: RE: [kmip] KMIP: RNG Proposals

> > Also, as an aside, if we are enumerating the various SP800-90(A) 
> > DRBG
> types, I assert we should leave off the Dual_EC DRBGs, if that hasn't 
> already been considered. ;->
> 
> I think they should remain with enumeration values specified ...  We 
> haven't made any specific recommendations in terms algorithms to not 
> use within KMIP to date and remember we do list DES and things like 
> RC2 within the algorithm list - see 9.1.3.2.13 within the KMIP 1.2 
> committee specification draft.

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?

Are there customer use cases out there involving (ahem) questionable crypto?  I'd understand if we had a long 20-year history and lots of legacy apps... but I don't think we have that.

Maybe I just get a Voldemort-like reaction to Dual_EC DRBG - "The algorithm that shall not be named". :-)

My $0.02.
-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 



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