Fw: ebXML response re GCM impacts

Forwarding to list...

Bruce A Rich
brich at-sign us dot ibm dot com

----- Forwarded by Bruce Rich/Austin/IBM on 12/13/2011 11:04 AM -----

From:   Moberg Dale <dmoberg@axway.com>
To:     Bruce Rich/Austin/IBM@IBMUS, "Kathryn.r.Breininger@boeing.com" 
<Kathryn.r.Breininger@boeing.com>
Cc:     "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
Date:   12/09/2011 01:13 PM
Subject:        RE: Potential XML encryption change



Sorry for the delay but I had not run into Galois Count mode, so I had to 
do some reading. After the developers and I went through the issues we 
currently have, we don’t see any worse problem than we already have.  (J)
 
Anecdotally speaking, no B2B files with large amounts of XML in them have 
turned up yet, partly because RosettaNet doesn’t yet have many using MMS 
ebMS or WSI and in automotive, using OAGIS BODs, we see dealer to OEM 
traffic, and the average size is moderate. And for those using straight 
WWS in SOAP, the messages so far are small.
 
EDI and other b2b data can reach gigabyte range, but it is mainly PKCS7 
over EDIINT-AS2. AS4 may change that, but that is probably still 2 years 
out. 
 
From: Bruce Rich [mailto:brich@us.ibm.com] 
Sent: Tuesday, November 29, 2011 11:37 AM
To: Moberg Dale; Kathryn.r.Breininger@boeing.com
Cc: Frederick.Hirsch@nokia.com
Subject: Potential XML encryption change
 
The W3C XML Security working group would like some feedback from the ebXML 
technical committee on some changes that are being discussed for XML 
encryption. 

Because of an increasing number of increasingly troublesome attacks on XML 
encryption, the working group is likely to propose that the current 
recommendation of encrypting with AES/CBC be changed to AES/GCM. 
Simply put, this change would sidestep the CBC-based attacks by 
automatically adding the equivalent of signing to the encryption process, 
which has the effect of adding signature verification to the decryption 
step. 
Although there are many technical reasons to adopt this change, GCM is not 
ideally-suited to large documents, as none of the cleartext should be 
returned from the decrypt step until the signature (tag) verification can 
be completed, which may require the entire document to be in memory. 
Initial thinking is that documents larger than 20 MB may be challenging 
for some environments to accommodate, so it is possible that although the 
Web Services community might not be impacted, your community might. 
Would you mind sharing with us your reading on the impact to ebXML?  Are 
there particular size ranges that you expect to have to handle as a matter 
of course? 

Thanks,
Bruce A Rich
brich at-sign us dot ibm dot com