# XML Security Working Group Teleconference

## 18 Oct 2011

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Bruce_Rich, Pratik_Datta, Frederick_Hirsch, Hal_Lockhart, Thomas_Roesser

Regrets

    Shivaram_Mysore, Frederick_Hirsch

Chair

    Frederick_Hirsch, Thomas_Roessler

Scribe

    brich

## Contents

  * [Topics][5]

    1. [Administrivia][6]

    2. [CBC][7]

    3. [Proposal to remove KeyLength for PBKDF2 in XML Encryption 1.1][8]

    4. [Editorial updates][9]

    5. [XML Encryption 1.1 and Interop][10]

    6. [XML Signature 2.0][11]

    7. [actions and issues][12]

  * [Summary of Action Items][13]

* * *

<trackbot> Date: 18 October 2011

<tlr> ScribeNick: brich

### Administrivia

<tlr> [http://lists.w3.org/Archives/Public/public-
xmlsec/2011Oct/att-0032/minutes-2011-10-11.html][14]

**RESOLUTION: minutes from 11 October approved**

### CBC

<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/][15] ]

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][16]

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][17]]

<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][18]]

<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][19]]

<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/][15]

### Proposal to remove KeyLength for PBKDF2 in XML Encryption 1.1

<fjh> [http://lists.w3.org/Archives/Public/public-
xmlsec/2011Oct/0017.html][20]

<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][21]]

<trackbot> Created ACTION-851 - Propose text regarding KeyLength and PBKDF2,
assuming we do not change the schemna [on Pratik Datta - due 2011-10-25].

### Editorial updates

<fjh> Please review XML Encryption 1.1 and algorithms document updates

<fjh> [http://lists.w3.org/Archives/Public/public-
xmlsec/2011Oct/0036.html][22] (Frederick)

<fjh> [http://lists.w3.org/Archives/Public/public-
xmlsec/2011Oct/0036.html][22] (Frederick)

<fjh> XML Security Algorithms document: [http://lists.w3.org/Archives/Public
/public-xmlsec/2011Oct/0047.html][23]

<fjh> Please review updated explain documents

<fjh> [http://lists.w3.org/Archives/Public/public-
xmlsec/2011Oct/0045.html][24] (Frederick)

<fjh> please review

### XML Encryption 1.1 and Interop

<fjh> [http://lists.w3.org/Archives/Public/public-
xmlsec/2011Oct/0018.html][25]

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][26]]

<trackbot> Created ACTION-852 - C14n2 and enc 1.1 test cases to publication
list [on Frederick Hirsch - due 2011-10-25].

### XML Signature 2.0

<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

### actions and issues

<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][27] -- due 2011-10-11 -- OPEN

<trackbot> [http://www.w3.org/2008/xmlsec/track/actions/840][28]

<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][29]

<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][30]]

<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

## Summary of Action Items

**[NEW]** **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][17]]

**[NEW]** **ACTION:** fjh to add new security issue later this week [recorded
in [http://www.w3.org/2011/10/18-xmlsec-minutes.html#action06][30]]

**[NEW]** **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][26]]

**[NEW]** **ACTION:** fjh to contact Microsoft re GCM and WS-Policy [recorded
in [http://www.w3.org/2011/10/18-xmlsec-minutes.html#action02][18]]

**[NEW]** **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][19]]

**[NEW]** **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][21]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][31] version 1.135 ([CVS
log][32])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0049.html

   [4]: http://www.w3.org/2011/10/18-xmlsec-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #ActionSummary

   [14]: http://lists.w3.org/Archives/Public/public-
xmlsec/2011Oct/att-0032/minutes-2011-10-11.html

   [15]: http://www.nds.rub.de/research/publications/breaking-xml-encryption/

   [16]: http://lists.w3.org/Archives/Member/member-xmlsec/2011Oct/0000.html

   [17]: http://www.w3.org/2011/10/18-xmlsec-minutes.html#action01

   [18]: http://www.w3.org/2011/10/18-xmlsec-minutes.html#action02

   [19]: http://www.w3.org/2011/10/18-xmlsec-minutes.html#action03

   [20]: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0017.html

   [21]: http://www.w3.org/2011/10/18-xmlsec-minutes.html#action04

   [22]: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0036.html

   [23]: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0047.html

   [24]: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0045.html

   [25]: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0018.html

   [26]: http://www.w3.org/2011/10/18-xmlsec-minutes.html#action05

   [27]: http://lists.w3.org/Archives/Public/public-xmlsec/2011Oct/0006.html

   [28]: http://www.w3.org/2008/xmlsec/track/actions/840

   [29]: http://www.w3.org/2008/xmlsec/track/actions/841

   [30]: http://www.w3.org/2011/10/18-xmlsec-minutes.html#action06

   [31]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [32]: http://dev.w3.org/cvsweb/2002/scribe/