Single suite requirement?

Black_David at emc.com Black_David at emc.com
Sun Sep 16 15:14:05 PDT 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
Gerry,
> I am also wondering what benefit there is in mandating support for a
> particular crypto suite. It seems unlikely that most peripherals
(e.g., a
> tape drive or disk drive) will have resources to support more than one
> crypto suite.
The benefit to a single suite is to simplify what has to be done to
ensure interoperability.  Not having anything specified results in
devices making choices and application clients having to implement
everything that might be found in a device (or at least the devices
they care about), which is approximately the current state of things
in SCSI.
> It is also likely that the "most favored choice" will change
> every couple years or will change for different markets (e.g., US
> government, foreign government, business, consumer).
Markets and timing definitely affect the choice of preferred crypto,
but the changes don't occur as rapidly as every couple of years - the
128-bit suite should be reasonable to use for at least a decade (e.g.,
NIST believes that the weakest portions of it (2048-bit RSA and DH)
are likely to be good through 2030.
> Governments and
> businesses tend to have procurement specs that enforce selections of
> features within a standard, so there is little need to mandate a
particular
> selection for the purpose of "conformance to a standard".  Since the
choice
> of which crypto(s) are supported is easy to discover there should be
little
> confusion about the reason for any incompatibility.
T10 is apparently somewhat looser about this than the IETF - the IETF
approach is that two implementations that conform to the same standard
should be capable of interoperating if appropriately configured.  It
looks
like you're willing to settle for there being a clear explanation of why
interoperability is not possible.  An example of the contrast is that
the US government IPv6 profiles tend to refer to IETF RFCs as whole
documents rather than making individual choices among their contents.
For reasons, I'll explain in one more message, I think mandating the
256-bit suite would be a major mistake.  Since Gideon's views are one
of the major reasons why the 256-bit suite was created, and Gideon
raised this question or whether to require any suite as mandatory,
let me propose the following alternative approach:
- We take the 256-bit suite out of 06-449 now, for reasons that start
	with the 521 bit elliptic curve that it contains - even the NSA
	doesn't require that (NSA's suite B requirements stop at the
	384-bit curve).
- The CAP vote to be taken becomes a vote on whether the 128-bit
	suite should be mandatory or not.  If it is not to be mandatory,
	CAP should then discuss whether to keep it around as some sort
	of recommendation.
In case you can't tell, I want to get 06-449 (IKEv2-SCSI) done - I
suspect
my managers are not the only people running out of patience with the
time
this has wound up taking.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
black_david at emc.com	   Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Gerry.Houlder at seagate.com
> Sent: Friday, September 14, 2007 4:06 PM
> To: t10 at t10.org
> Subject: RE: 256-bit vs 512-bit strength security
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> I am also wondering what benefit there is in mandating support for a
> particular crypto suite. It seems unlikely that most 
> peripherals (e.g., a
> tape drive or disk drive) will have resources to support more than one
> crypto suite. It is also likely that the "most favored 
> choice" will change
> every couple years or will change for different markets (e.g., US
> government, foreign government, business, consumer). Governments and
> businsses tend to have procurement specs that enforce selections of
> features within a standard, so there is little need to 
> mandate a particular
> selection for the purpose of "conformance to a standard".  
> Since the choice
> of which crypto(s) are supported is easy to discover there 
> should be little
> confusion about the reason for any incompatibility.
> 
> 
> 
>								
>	       
>	       "Gideon Avida"					
>	       
>	       <gideon at decru.com				
>	       
>	       >						
>	    To 
>	       Sent by: 		 "Kevin D Butt" 
> <kdbutt at us.ibm.com>  
>	       owner-t10 at t10.org				
>	    cc 
>	       No Phone Info		 "Ralph Weber" 
> <roweber at IEEE.org>,	
>	       Available		 <t10 at t10.org>		
>	       
>								
>      Subject 
>					 RE: 256-bit vs 512-bit 
> strength     
>	       09/14/2007 11:54 	 security		
>	       
>	       AM						
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
> 
> 
> 
> 
> Kevin,
> 
> Whether or not the NSA document support's the argument about 
> IP depends on
> how you interpret "the intellectual property environment surrounding
> elliptic curves". One should wonder why they didn't use the word
> "covering".
> 
> As for the RAND statement (and I'm not implying that it is or isn't
> necessary): since ietf has been able to receive such 
> statements, it seems
> that there's a good chance that T10 could too...
> 
> Even if you only focus on government agencies, we still 
> believe that there
> is a need for 256 bit secure products.
> 
> Since we seem to be entrenched in our positions, maybe we 
> should reconsider
> the merits of mandating support for any crypto suite...
> 
> Cheers,
> Gideon
> 
> From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
> Sent: Thursday, September 13, 2007 5:40 PM
> To: Gideon Avida
> Cc: owner-t10 at t10.org; Ralph Weber; t10 at t10.org
> Subject: RE: 256-bit vs 512-bit strength security
> 
> 
> Gideon,
> 
> Your link below supports the argument about IP.
> Quoted from the article:
> "Despite the many advantages of elliptic curves and despite 
> the adoption of
> elliptic curves by many users, many vendors and academics view the
> intellectual property environment surrounding elliptic curves 
> as a major
> roadblock to their implementation and use. "
> 
> A close reading on this section about IP will show that 
> unless you are "
> limited to implementations that were for national security 
> uses " then you
> must license at least 26 of the patents held by the 
> referenced company.
> 
> Without a Reasonable and Non-Descriminatory statement from 
> those that hold
> the IP, then all would be held to getting licenses from a company -
> potentially your competitor - under terms that do not meet 
> RAND.  In fact,
> there is no guarantee that you could even license that IP.
> 
> The other point to argue, the statement "We've found that many
> non-government customers refer to these documents
> for guidance" is the assertion of what your customers may be 
> stating.  I
> don't know if the customers to whom you are referring is 
> isolated to your
> customers only or to customers of a few companies.  However, 
> I do know that
> I have not heard any of our customers making this statement.	
> Just because
> one companies or a few companies need to support something for their
> customers should not require that all other companies should 
> be forced to
> support that to be compliant with the standards.  This is why 
> there are
> optional values allowed.  We mandate what can be supported by 
> all companies
> and make the rest optional.  In this case, there is the IP 
> issue that is a
> road block to some companies and there is also a lack of need 
> by either
> those same companies or a different set of companies.  They 
> meet	their
> needs by using the 128 bit strength algorithms.
> 
> Thanks,
> 
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
> 
>								
>	       
>  "Gideon Avida"						
>	       
>  <gideon at decru.com>						
>	       
>  Sent by: owner-t10 at t10.org					
>	       
>								
>	    To 
>					     Kevin D 
> Butt/Tucson/IBM at IBMUS   
>  09/13/2007 01:03 PM						
>	    cc 
>					     "Ralph Weber"	
>	       
>					     
> <roweber at IEEE.org>,		  
>					     <t10 at t10.org>	
>	       
>								
>      Subject 
>					     RE: 256-bit vs 
> 512-bit strength 
>					     security		
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
> 
> 
> 
> 
> 
> Hi Kevin,
> 
> Since I'm not sure how navigate this minefield, I'll just 
> point to another
> NSA document: http://www.nsa.gov/ia/industry/crypto_elliptic_curve.cfm
> 
> Thanks,
> Gideon
> 
> From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
> Sent: Thursday, September 13, 2007 12:58 PM
> To: Gideon Avida
> Cc: Ralph Weber; t10 at t10.org
> Subject: RE: 256-bit vs 512-bit strength security
> 
> 
> Thanks Gideon,
> 
> I will also reiterate what I said in Colorado Springs, we 
> cannot support as
> mandatory, items that fall under the IP of companies that do 
> not make a
> RAND statement to T10 related to that IP.
> 
> Thanks,
> 
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
>								
>	       
>  "Gideon Avida"						
>	       
>  <gideon at decru.com>						
>	       
>								
>	       
>								
>	    To 
>  09/13/2007 12:35 PM			     Kevin D 
> Butt/Tucson/IBM at IBMUS   
>								
>	    cc 
>					     <t10 at t10.org>, 
> "Ralph Weber"    
>					     <roweber at IEEE.org> 
>	       
>								
>      Subject 
>					     RE: 256-bit vs 
> 512-bit strength 
>					     security		
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
>								
>	       
> 
> 
> 
> 
> 
> 
> Hi Kevin (and everyone else...),
> 
> As I said in Colorado Springs, this isn't about cryptography 
> but rather
> about policies.
> 
> For example, CNSS Policy No. 15, Fact Sheet No. 1 - National Policy on
> the Use of the Advanced Encryption Standard (AES) to Protect National
> Security Systems and National Security Information
> (http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf) says:
> The design and strength of all key lengths of the AES algorithm (i.e.,
> 128, 192 and 256) are sufficient to protect classified 
> information up to
> the SECRET level. TOP SECRET information will require use of 
> either the
> 192 or 256 key lengths.
> 
> The NSA took it further in Suite B
> (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm) by specifying the
> algorithms to use for encryption (AES), digital signatures and key
> exchange (ECC based) and hashing (SHA). They also say there: "NSA has
> determined that beyond the 1024-bit public key cryptography in common
> use today, rather than increase key sizes beyond 1024-bits, a 
> switch to
> elliptic curve technology is warranted."
> 
> We've found that many non-government customers refer to these 
> documents
> for guidance. We've also found that they prefer to not have 
> to classify
> their information and to simplify things would like to use 
> AES-256 to be
> on the safe side. They also like to use the same level security
> throughout the datacenter so they don't have to justify using lower
> levels of security in some areas of the datacenter to the auditors.
> 
> Hope this helps the undecided crowd (and maybe convert a few from the
> 128 bit crowd...)
> 
> Cheers,
> Gideon
> ________________________________
> 
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Kevin D
> Butt
> Sent: Thursday, September 13, 2007 11:20 AM
> To: Ralph Weber
> Cc: owner-t10 at t10.org; 't10 at t10.org'
> Subject: Re: 256-bit vs 512-bit strength security
> 
> 
> 
> All,
> 
> I would like to share what Hugo Krawczyk, one of IBM's cryptographers
> has shared with me.
> <<
> The 256-strength suite is total overkill.
> There is no need to use AES with 256-bit key today or SHA-512.
> Of course, the 128-bit suite may be broken next month (or in 5 years)
> but the same is possible
> for the 256-bit suite. Actually, who said 500-bit EC will not turn out
> to have only 128 bit of security in a
> breakthrough cryptanalysis in 5-10 years (or next month)?
> 
> Given the information we have today, the 128-bit suite is good enough
> for almost all commercial applications.
> If you need security of your data for the next 50 years you 
> may consider
> going to a stronger suite, but then
> (again) who said that the 256-bit will suffice? (for 50 year 
> security I
> recommend sending it inside a physical safe :)
> 
> The only reason I see now for going for a 256-bit suite is to promote
> ECC.
> That may or may not be a good idea, but it should be clear that that's
> the only relevant reason for this suite.
> 
> Hugo
> >>
> 
> Thanks,
> 
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
> 
> 
> 
> Ralph Weber <roweber at IEEE.org>
> Sent by: owner-t10 at t10.org
> 
> 09/12/2007 07:25 PM
> 
> 
> To
>		 "'t10 at t10.org'" <t10 at t10.org>
> cc
> 
> Subject
>		 256-bit vs 512-bit strength security
> 
> 
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> Reminder:
> 
> On Wednesday afternoon in Vancouver, you will be asked
> to vote your company's position on a choice between
> mandating 256-bit strength security or 512-bit strength
> security in SPC-4.
> 
> If you do not yet know your company's position,
> now would be a good time to start asking some
> embarrassing questions.
> 
> All the best,
> 
> .Ralph
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list