Re: [jose] #28: AES-GCM should not be allowed for content encryption in combination with Direct Encryption key management mode

["jose issue tracker" <[e-mail]>]

#28: AES-GCM should not be allowed for content encryption in combination with
Direct Encryption key management mode


Comment (by [e-mail]):

 What's practical for applications depends entirely upon the application
 context.  For many applications, the rate of encryption transactions by
 itself means that 2-to-the-32 encryption operations will never be
 performed, and so no "keeping track" would be needed.  2-to-the-32 is big.
 For instance, it would take 136 years to do that many encryptions at a
 rate of one per second.  If the algorithm is used to encrypt daily updates
 of information, you'd have over 49,000 years of updates before hitting the
 limit.

 We've told applications that they must not exceed this limit.  We've given
 them other algorithms without this limit - notably McGrew's
 AES_CBC_HMAC_SHA2 algorithms.  If applications choose to not heed these
 constraints, I'm sure that we have bigger problems. There are a lot easier
 ways they can hurt themselves by not heeding other usage constraints.

 For instance, if they ignore what's said about safely using the JOSE
 crypto encodings, they could always use zero initialization vector values.
 They could publish their symmetric and private keys on publicly accessible
 Internet sites.  They could use random number generators and key
 generators that produce constant or predictable values.  Etc.

 Yes, it's possible to use direct encryption with GCM in an unsafe manner.
 It's possible to use all the crypto operations in an unsafe manner.  The
 key is that we've clearly told applications how to not do that.  If they
 choose to ignore what the specs say about how to use the crypto operations
 safely, there's very little we can do to prevent that.  (Heck, even if we
 accepted your proposed action for this issue, they could ignore a
 prohibition not to use GCM for direct encryption as well! :-) )  I think
 we've already fulfilled our responsibilities to implementers and
 applications by clearly saying how to do safe crypto, both in this
 particular case, and in others.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  [e-mail]        |  [e-mail]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  algorithms             |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/28#comment:5>
jose <http://tools.ietf.org/jose/>