[Openid-specs-ab] Encryption

Nat Sakimura sakimura at gmail.com
Sat Oct 29 22:05:38 UTC 2011


Let us bring it up in Taipei, then.

FYI, I initially thought the same as you, but after some contemplation, I
changed my opinion.
My reasoning for HMACing with encryption was:

1) Encrypt then hmac in nested operation, it will blow up the size.
2) Encrypt then hmac in nested operation, how to exchange the key for the
hmac becomes an issue.

I cannot come up with a good solution for these as long as I keep them as
two separate steps.

If Encrypt and hmac is done as a combined operation to create a JWT, then
both problems goes away.

=nat

On Sun, Oct 30, 2011 at 5:13 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  I’d bring it up on Taipei.  In-person discussions on topics of this
> complex nature are more likely to generate consensus (in my experience)
> during face-to-face discussions than on e-mail lists.****
>
> ** **
>
> As a technical point, I’d hate to see HMAC be required when nested
> Encryption and Signing operations are another perfectly valid mechanism for
> achieving the same ends.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Nat Sakimura
> *Sent:* Saturday, October 29, 2011 1:11 PM
> *To:* John Bradley
>
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Encryption****
>
>  ** **
>
> HMACing with CEK and have that in JWE spec as REQUIRED in case of CBC would
> be really nice. ****
>
> ** **
>
> Maybe I should post it in Jose list or bring it up in Taipei.
>
> =nat via iPhone****
>
>
> On 2011/10/30, at 3:54, John Bradley <ve7jtb at ve7jtb.com> wrote:****
>
>  ** **
>
> On 2011-10-29, at 3:42 PM, Nat Sakimura wrote:****
>
>
>
> ****
>
>
>
> =nat via iPhone****
>
>
> On 2011/10/30, at 2:52, John Bradley <ve7jtb at ve7jtb.com> wrote:****
>
>    ** **
>
> The reality is that we are not going to be able to REQUIRE AES-GWC any time
> soon.****
>
>  ** **
>
> +1 though keep pressuring the implementations to support GCM etc. should
> continue. ****
>
>
>
> ****
>
> ** **
>
> I think that libraries not providing padding oracles and other side
> channels is important to be clear about.  ****
>
> ** **
>
> AES-CBC is still something important to support.   ****
>
> ** **
>
> One possible combination is using zip ****
>
>
> gzip I guess. ****
>
> ** **
>
> JWE refers to it as zip, but it is deflate in a gzip container (not zlib).
>  I am looking for some better wording for the JWE spec.****
>
>
>
> ****
>
>
>
> ****
>
> with AES-CBC and not differentiating between padding and inflate errors.
>  The CRC32 integrity check over the uncompressed source would foil the
> oracle attack.****
>
> ** **
>
> That should make it significantly harder though it may not be impossible.
> ****
>
> ** **
>
> There are a bunch of implementation details around error reporting that
> would determine that.  one would be how you report invalid content type if
> someone removed the zip flag from the envelope.****
>
> ** **
>
> So perfect is hard,  however we do have other tools like reporting signing
> and encrypting errors as a composite value where we encrypt a signed object.
> ****
>
> ** **
>
> GWC also has some issues with long cypher texts so is not pure magic on
> it's own.****
>
> ** **
>
> John B.****
>
>
>
> ****
>
> ** **
>
> John B.****
>
> On 2011-10-29, at 7:17 AM, Rob Richards wrote:****
>
>
>
> ****
>
> Mike,
>
> Do you have a patch for the support already? As long as there's no BC
> issues I might be able to get it into the 5.4 candidate before it's
> released. I had just started looking at adding support due to the xml enc
> issue but would be extremely helpful if you already had a patch. Also if you
> happen to know which openssl versions the patch works with as it appears
> there are a number of ways to use GCM depending upon the version.
>
> Rob
>
> On 10/28/11 12:18 PM, Mike Jones wrote:
>
> ****
>
> We pretty much reached the same conclusion during the encryption working
> group session at IIW.  The only problem, as Nat pointed out, is that PHP
> libraries, as currently distributed, do not support GCM (although the
> underlying OpenSSL libraries that PHP uses do).  Of course, maybe we can use
> this as a forcing function to get PHP to support GCM by default (without
> requiring recompilation, which is possible now).****
>
> ** **
>
>                                                  -- Mike****
>
>  ** **
>
>  -----Original Message-----****
>
>  From: openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] On Behalf Of Anthony Nadalin****
>
>  Sent: Friday, October 28, 2011 9:13 AM****
>
>  To: Axel.Nennker at telekom.de; jbradley at mac.com****
>
>  Cc: openid-specs-ab at lists.openid.net****
>
>  Subject: Re: [Openid-specs-ab] Encryption****
>
>  ** **
>
>  As I see it we need to require the GCM mode of operation (an
> authenticated encryption mode) for AES (moving AES-GCM from option to
> mandatory).****
>
>  ** **
>
>  -----Original Message-----****
>
>  From: openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] On Behalf Of
> Axel.Nennker at telekom.de****
>
>  Sent: Friday, October 28, 2011 8:55 AM****
>
>  To: jbradley at mac.com****
>
>  Cc: openid-specs-ab at lists.openid.net****
>
>  Subject: Re: [Openid-specs-ab] Encryption****
>
>  ** **
>
>  Here is the link to the paper:****
>
>
> http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf
> ****
>
>  ** **
>
>  The authors recommend "One possibility to avoid our attack is to use a
> symmetric cryptographic primitive that does not only provide
> confidentiality, but also integrity. This can for instance be achieved by
> replacing the CBC mode of operation with a mode that provides message
> integrity. Adequate choices have for instance been standardized in ISO/IEC
> 19772:2009. We consider this solution as very recommendable for future
> versions of the XML Encryption standard. Unfortunately, this may bring
> deployment and backwards compatibility issues."****
>
>  ** **
>
>  http://www.iso.org/iso/catalogue_detail?csnumber=46345****
>
>  ** **
>
>  -Axel****
>
>  ** **
>
>  -----Original Message-----****
>
>  From: John Bradley [mailto:jbradley at mac.com]****
>
>  Sent: Freitag, 28. Oktober 2011 16:22****
>
>  To: Nennker, Axel****
>
>  Cc: Nat Sakimura; Michael Jones; openid-specs-ab at lists.openid.net****
>
>  Subject: Re: [Openid-specs-ab] Encryption****
>
>  ** **
>
>  We don't encryption it, but we do support it.****
>
>  ** **
>
>  I haven't seen the original paper only analysis of it.****
>
>  ** **
>
>  Mike should be able to get it.****
>
>  ** **
>
>  I don't think we should panic.   I have known about this for a week or
> so.****
>
>  ** **
>
>  While the problem involves CBC it is not necessarily a CBC algorithm
> vulnerability in itself.****
>
>  ** **
>
>  The problem is likely the xmlenc API error messages and having them
> reported back over SOAP.****
>
>  ** **
>
>  As long as we are careful about not communicating too much in the error
> message and implementers protect against side channel timing attacks, JWE
> probably is OK as is with appropriate security considerations.****
>
>  ** **
>
>  I would be surprised if the attack works agains AES-CBC + RSA.****
>
>  ** **
>
>  It also probably is ineffective agains AES-CBC+keywrap.****
>
>  ** **
>
>  Yes GWC is better that is why it was created.****
>
>  ** **
>
>  We need the paper before trying to fix things that may not need fixing.**
> **
>
>  ** **
>
>  John B.****
>
>  ** **
>
>  ** **
>
>  ** **
>
>  ** **
>
>  On 2011-10-28, at 10:13 AM, Axel.Nennker at telekom.de wrote:****
>
>  ** **
>
>  Do we actually require encryption in the openid connect standards? I
> thought we refer to JWS and JWS and that's it?****
>
>   Axel****
>
>   ** **
>
>   ** **
>
>   ** **
>
>   ** **
>
>   -----Original Message-----****
>
>   From: openid-specs-ab-bounces at lists.openid.net****
>
>   [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of****
>
>   sakimura****
>
>   Sent: Freitag, 28. Oktober 2011 13:36****
>
>   To: Mike Jones; John Bradley; Anthony Nadalin; Openid specs ab****
>
>   Subject: [Openid-specs-ab] Encryption****
>
>   ** **
>
>   So I was going over the recent XML Encryption vulnerability.****
>
>   http://www.informationweek.com/news/security/vulnerabilities/231901532**
> **
>
>   ** **
>
>   The flaw is that of CBC mode of operation combined with****
>
>   unauthenticated encryption.****
>
>   It is a kind of padding oracle attack.****
>
>   ** **
>
>   We have two choices here:****
>
>   ** **
>
>   1) Require authenticated encryption mode such as GCM****
>
>   2) Require message authentication to be applied to the cipher text.****
>
>   ** **
>
>   Ideally 1) should be taken as operational efficiency is much greater****
>
>   than 2), but in reality we do not have support for GCM in many****
>
>   languages.****
>
>   ** **
>
>   Thus, while RECOMMENDing 1), we should REQUIRE HMAC to be applied on****
>
>   the encrypted text (cipher text) in CBC mode.****
>
>   ** **
>
>   Thus, we should make it REQUIRED to sig+enc+mac, instead of sig+enc,****
>
>   and REQUIRE the verifier to first verify the mac and if the mac is not**
> **
>
>   correct the process should abend returning mac error.****
>
>   ** **
>
>   Also, although same public-private keypair can be used for encryption***
> *
>
>   and signature in case of RSA, we should probably use two separate****
>
>   keypair. That is safer.****
>
>   Perhaps we would not REQUIRE it, but we should RECOMMEND it.****
>
>   ** **
>
>   =nat****
>
>   ** **
>
>   _______________________________________________****
>
>   Openid-specs-ab mailing list****
>
>   Openid-specs-ab at lists.openid.net****
>
>   http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>  _______________________________________________****
>
>  Openid-specs-ab mailing list****
>
>  Openid-specs-ab at lists.openid.net****
>
>  http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>  ** **
>
>  ** **
>
>  ** **
>
>  ** **
>
>  _______________________________________________****
>
>  Openid-specs-ab mailing list****
>
>  Openid-specs-ab at lists.openid.net****
>
>  http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>  ** **
>
>  _______________________________________________****
>
>  Openid-specs-ab mailing list****
>
>  Openid-specs-ab at lists.openid.net****
>
>  http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>  ** **
>
> ** **
>
> ** **
>
> ** **
>
>  _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>   ** **
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111030/70fac70b/attachment-0001.html>


More information about the Openid-specs-ab mailing list