See also: IRC log
<trackbot> Date: 18 October 2011
<tlr> ScribeNick: brich
<tlr> http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/att-0032/minutes-2011-10-11.html
RESOLUTION: minutes from 11 October approved
<scantor> which paper is this? (the title)
<fjh> [Note, link to paper (added after call): http://www.nds.rub.de/research/publications/breaking-xml-encryption/ ]
tlr: the paper suggests an attack based on back-channels that works successfully plus SOAP+XMLEnc is brittle
<tlr> Jäger, Somorovsky, "How to Break XML Encryption"
tlr: GCM may not be acceptable for large documents
... is there a different recommendation that we should make?
... wrapping attacks still possible, as SOAP allows inclusion at a different, unprotected location
<fjh> proposal on member list: http://lists.w3.org/Archives/Member/member-xmlsec/2011Oct/0000.html
Hal: paper suggests even signatures may not completely defend against the attacks possible
<tlr> tlr: do we need GCM? Do we need something else?
<tlr> … what are the tradeoffs?
<tlr> brich: Have looked at GCM; framework support in Java
<tlr> … working on implementations
<tlr> … did note that spec one is not supposed to return any cleartext before some tag is verified
<tlr> … cannot really use this for at least large objects
<tlr> … might be able to do double processing
<tlr> tlr: is the "process everything" piece part of important security properties?
<tlr> brich: not sure
<tlr> … but essence is, get nothing if signature doesn't validate; need to get to end of this particular piece
<tlr> … at that point, have all cleartext and all cipher text in memory
<tlr> hal: confused about context
<tlr> brich: counter modes — gcm or ccm
<tlr> … tag that flows along with encrypted data
<tlr> … in essence a signature of encrypted data + some other things you don't want to have tampered
<tlr> hal: if you have integrity check over object, need to read the entire object
<tlr> brich: not possible to do streaming decryption where one gets cleartext piece by piece
<tlr> hal: well, you could ignore the integrity features
<tlr> tlr: yeah, but
<tlr> hal: could chunk things?
<tlr> brich: gcm needs everything in memory, both sending side and reading side
<tlr> … on receiving side, need to have cipher text, cleartext, tag, tag verification results in memory
<tlr> pdatta: why cipher text in memory on sending side? Tag is on end of data.
<tlr> scantor: signature may actually work, with implementations fixed
<tlr> … don't dismiss out of hand
<tlr> brich: gcm or ccm are probably the countermeasure within scope for this spec
<scantor> in particular given that GCM ain't gonna be around immediately
<tlr> … do not know of a superior solution
<tlr> tlr: and so, to understand where we are — gcm and ccm not broadly deployed?
<tlr> brich: correct
<tlr> tlr: GREAT!
<tlr> brich: in web services context, best fix is encrypt-then-sign
<tlr> … get to test one of the least tested modes for ws-security
<tlr> hal: better security considerations?
<tlr> brich: best practices?
<tlr> hal: limit size of what you encrypt
<fjh> summary, use GCM but adjustment required for large data sizes
<fjh> if gcm is made mandatory then how will interop for CR work if GCM is not deployed
<scantor> at an initial glance, OpenSSL either has no GCM support, or it's only in the latest version
<fjh> sounds like an XML Encryption 2.0 might be coming into existance
<fjh> issue with GCM is that it cannot be streamed well, so issue for large data in terms of memory etc, might require some additional design work
<fjh> can consider making GCM mandatory in 1.1 but need to first ask implementers about deployment
<fjh> hal notes that most deployments other than open source use libraries, thus switching on GCM might not be so hard
<fjh> sounds like making GCM mandatory in 1.1 helps but not solution for large data
<fjh> tlr suggests protocol with separate keys for chunks, a design project
Hal: since the paper is released tomorrow, perhaps can put more detail in these minutes, and have them on public list
scantor: implications on doFinal decryption mode vs GCM, OpenSSL wouldn't necessarily comply with don't-return-plaintext-until-tag-verifies
<fjh> web services can use WS-Policy to encrypt then sign, but may have implementation glitches, potential issue with wrapping attacks
<fjh> question - is encrypt then sign required
tlr: if do sign, then encrypt, then the paper indicates that can tell whether guessing attack worked through timing
Hal: what's feasibility of making authenticated modes mandatory, then doing interop?
... might need to be warning some communities (e.g., SAML) about encrypting single fields
<fjh> tlr proposes creating new spec for enabling use of GCM for chunking large data
<scantor> docs might be out of date, but NSS also appears to be lacking any GCM
Hal: what is the usecase for large encrypted objects?
<fjh> ACTION: brich to contact OASIS ebXML community regarding large data issue and GCM [recorded in http://www.w3.org/2011/10/18-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-848 - Contact OASIS ebXML community regarding large data issue and GCM [on Bruce Rich - due 2011-10-25].
tlr: net is that we're leaning toward AES-GCM and MTI, and need to interop around it
pdatta: do we need to recommend not reusing a particular key a certain number of times?
Hal: in a symmetric key case, this would be a reasonable recommendation
tlr: would work until someone comes up with a related-key attack variant
... need to contact the microsoft and rsa folks to see about their GCM posture
... need security considerations update
<fjh> ACTION: fjh to contact Microsoft re GCM and WS-Policy [recorded in http://www.w3.org/2011/10/18-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-849 - Contact Microsoft re GCM and WS-Policy [on Frederick Hirsch - due 2011-10-25].
<tlr> ACTION: hal to review XML Encryption 1.1 security considerations and propose changes in light of today's discussion [recorded in http://www.w3.org/2011/10/18-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-850 - Review XML Encryption 1.1 security considerations and propose changes in light of today's discussion [on Hal Lockhart - due 2011-10-25].
<fjh> Frederick resumed chairing
<fjh> pdatta: asks about ssl protection
<fjh> what about SOAP intermediaries?
Hal: traffic you can't see, can't be attacked
<tlr> -> SSL effective defense
pdatta: using ws-security on top of SSL would introduce another layer of defense that doesn't open the same vulnerabilities
<fjh> this might be a practical approach in some case
<tlr> http://www.nds.rub.de/research/publications/breaking-xml-encryption/
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0017.html
<fjh> typically keylength determined from context, not explicit usually
pdatta: if specified doesn't match the context, what would be the behavior?
... will propose some text
<fjh> ACTION: pdatta to propose text regarding KeyLength and PBKDF2, assuming we do not change the schemna [recorded in http://www.w3.org/2011/10/18-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-851 - Propose text regarding KeyLength and PBKDF2, assuming we do not change the schemna [on Pratik Datta - due 2011-10-25].
<fjh> Please review XML Encryption 1.1 and algorithms document updates
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0036.html (Frederick)
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0036.html (Frederick)
<fjh> XML Security Algorithms document: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0047.html
<fjh> Please review updated explain documents
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0045.html (Frederick)
<fjh> please review
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0018.html
pdatta: added GCM, among other things
... testcases for key agreement and transport
... lots of combinations for OAEP, longer key lengths
... suite B tests defined
... will take a few more weeks to complete tables
<fjh> volunteers to test with this are needed...
<fjh> much thanks to pratik
<fjh> ACTION: fjh to c14n2 and enc 1.1 test cases to publication list [recorded in http://www.w3.org/2011/10/18-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-852 - C14n2 and enc 1.1 test cases to publication list [on Frederick Hirsch - due 2011-10-25].
<fjh> pratik completed edit and follow up on LC-2488
<fjh> I believe all edits etc are complete on 2.0, focus appears to be on encryption 1.1.
<fjh> talk 1:30-3:30 central
<fjh> ACTION-840?
<trackbot> ACTION-840 -- Pratik Datta to update XML Signature 1.1 and 2.0 with change in http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0006.html -- due 2011-10-11 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/840
<fjh> ACTION-841?
<trackbot> ACTION-841 -- Pratik Datta to add link to canonical XML 2.0 samples into the spec -- due 2011-10-11 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/841
<fjh> fjh: to add new security issue later this week
<fjh> ACTION: fjh to add new security issue later this week [recorded in http://www.w3.org/2011/10/18-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-853 - Add new security issue later this week [on Frederick Hirsch - due 2011-10-25].
fjh: wonders if we could have addressed this attack better/earlier
tlr: with the amount of time we were given, could we have provided a better forum for implementers to get more technology deployed?
<fjh> hal: wg did what is logical and appropriate for working on the specification