<html><head></head><body bgcolor="#FFFFFF"><div>HMACing with CEK and have that in JWE spec as REQUIRED in case of CBC would be really nice. </div><div><br></div><div>Maybe I should post it in Jose list or bring it up in Taipei. <br>
<br>=nat via iPhone</div><div><br>On 2011/10/30, at 3:54, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br><div><div>On 2011-10-29, at 3:42 PM, Nat Sakimura wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div><br><br>=nat via iPhone</div><div><br>On 2011/10/30, at 2:52, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br>
<br></div><blockquote type="cite">
<div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><div>The reality is that we are not going to be able to REQUIRE AES-GWC any time soon.</div>
</div></div></div></div></blockquote><div><br></div>+1 though keep pressuring the implementations to support GCM etc. should continue. <div><br><blockquote type="cite"><div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div><div><br></div><div>I think that libraries not providing padding oracles and other side channels is important to be clear about. </div><div><br></div><div>AES-CBC is still something important to support. </div><div>
<br></div><div>One possible combination is using zip </div></div></div></div></div></blockquote><br>gzip I guess. </div></div></blockquote><div><br></div>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.</div>
<div><br><blockquote type="cite"><div bgcolor="#FFFFFF"><div><br><blockquote type="cite"><div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div><div>with AES-CBC and not differentiating between padding and inflate errors. The CRC32 integrity check over the uncompressed source would foil the oracle attack.</div></div></div></div></div></blockquote><div><br>
</div>
</div><div>That should make it significantly harder though it may not be impossible. </div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>GWC also has some issues with long cypher texts so is not pure magic on it's own.</div>
<div><br></div><div>John B.</div><blockquote type="cite"><div bgcolor="#FFFFFF"><div><br><blockquote type="cite"><div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div><div><br></div><div>John B.</div><div><div>On 2011-10-29, at 7:17 AM, Rob Richards wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Mike,<br><br>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.<br>
<br>Rob<br><br>On 10/28/11 12:18 PM, Mike Jones wrote:<br><blockquote type="cite">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).<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>-- Mike<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Anthony Nadalin<br>
</blockquote><blockquote type="cite">Sent: Friday, October 28, 2011 9:13 AM<br></blockquote><blockquote type="cite">To: <a href="mailto:Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>; <a href="mailto:jbradley@mac.com">jbradley@mac.com</a><br>
</blockquote><blockquote type="cite">Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br></blockquote><blockquote type="cite">Subject: Re: [Openid-specs-ab] Encryption<br></blockquote>
<blockquote type="cite"><br></blockquote><blockquote type="cite">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).<br></blockquote>
<blockquote type="cite"><br></blockquote><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of <a href="mailto:Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a><br>
</blockquote><blockquote type="cite">Sent: Friday, October 28, 2011 8:55 AM<br></blockquote><blockquote type="cite">To: <a href="mailto:jbradley@mac.com">jbradley@mac.com</a><br></blockquote><blockquote type="cite">Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
</blockquote><blockquote type="cite">Subject: Re: [Openid-specs-ab] Encryption<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Here is the link to the paper:<br></blockquote><blockquote type="cite">
<a href="http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf">http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf</a><br></blockquote><blockquote type="cite">
<br></blockquote><blockquote type="cite">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."<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="http://www.iso.org/iso/catalogue_detail?csnumber=46345">http://www.iso.org/iso/catalogue_detail?csnumber=46345</a><br></blockquote><blockquote type="cite">
<br></blockquote><blockquote type="cite">-Axel<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: John Bradley [mailto:<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>]<br>
</blockquote><blockquote type="cite">Sent: Freitag, 28. Oktober 2011 16:22<br></blockquote><blockquote type="cite">To: Nennker, Axel<br></blockquote><blockquote type="cite">Cc: Nat Sakimura; Michael Jones; <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
</blockquote><blockquote type="cite">Subject: Re: [Openid-specs-ab] Encryption<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We don't encryption it, but we do support it.<br></blockquote>
<blockquote type="cite"><br></blockquote><blockquote type="cite">I haven't seen the original paper only analysis of it.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Mike should be able to get it.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I don't think we should panic. I have known about this for a week or so.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">
While the problem involves CBC it is not necessarily a CBC algorithm vulnerability in itself.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The problem is likely the xmlenc API error messages and having them reported back over SOAP.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I would be surprised if the attack works agains AES-CBC + RSA.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">
It also probably is ineffective agains AES-CBC+keywrap.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes GWC is better that is why it was created.<br></blockquote><blockquote type="cite">
<br></blockquote><blockquote type="cite">We need the paper before trying to fix things that may not need fixing.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">John B.<br></blockquote><blockquote type="cite">
<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 2011-10-28, at 10:13 AM, <a href="mailto:Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a> wrote:<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Do we actually require encryption in the openid connect standards? I thought we refer to JWS and JWS and that's it?<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Axel<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
-----Original Message-----<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><br></blockquote>
</blockquote><blockquote type="cite"><blockquote type="cite">[mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of<br></blockquote></blockquote><blockquote type="cite">
<blockquote type="cite">sakimura<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sent: Freitag, 28. Oktober 2011 13:36<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
To: Mike Jones; John Bradley; Anthony Nadalin; Openid specs ab<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: [Openid-specs-ab] Encryption<br></blockquote></blockquote><blockquote type="cite">
<blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So I was going over the recent XML Encryption vulnerability.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<a href="http://www.informationweek.com/news/security/vulnerabilities/231901532">http://www.informationweek.com/news/security/vulnerabilities/231901532</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The flaw is that of CBC mode of operation combined with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">unauthenticated encryption.<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It is a kind of padding oracle attack.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote>
<blockquote type="cite">
<blockquote type="cite">We have two choices here:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1) Require authenticated encryption mode such as GCM<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2) Require message authentication to be applied to the cipher text.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Ideally 1) should be taken as operational efficiency is much greater<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
than 2), but in reality we do not have support for GCM in many<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">languages.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
Thus, while RECOMMENDing 1), we should REQUIRE HMAC to be applied on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the encrypted text (cipher text) in CBC mode.<br></blockquote></blockquote>
<blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thus, we should make it REQUIRED to sig+enc+mac, instead of sig+enc,<br></blockquote></blockquote>
<blockquote type="cite"><blockquote type="cite">and REQUIRE the verifier to first verify the mac and if the mac is not<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">correct the process should abend returning mac error.<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Also, although same public-private keypair can be used for encryption<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and signature in case of RSA, we should probably use two separate<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">keypair. That is safer.<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Perhaps we would not REQUIRE it, but we should RECOMMEND it.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote>
</blockquote><blockquote type="cite"><blockquote type="cite">=nat<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Openid-specs-ab mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Openid-specs-ab mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
</blockquote><blockquote type="cite"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></blockquote><blockquote type="cite"><br></blockquote>
<blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">
Openid-specs-ab mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br></blockquote><blockquote type="cite"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Openid-specs-ab mailing list<br></blockquote><blockquote type="cite">
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br></blockquote><blockquote type="cite"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br></div></div></div><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br>
<span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br>
</div></blockquote></div></div>
</blockquote></div><br></div></blockquote></body></html>