<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I agree we need to put pressure on the underlying libraries. The only think I know about openSSL is that IBM contributed a patch some time ago, and there is talk on their list about GCM being in 1.1.<div><br></div><div>I don't have anything more than that at this point.</div><div><br></div><div>John B.<br><div><div>On 2011-10-31, at 11:24 AM, Rob Richards wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
I agree that there is no way it can be required at this time but
from my perspective nows the time to at least get the algorithm
support added to underlying libraries so it can be eventually used.
Was hoping someone here had a patch already. In regards to openssl
do you happen to know if in 1.1.0 it was just the EVP support for
GCM added or was this the initial exposing of GCM for en/decrpytion?
I havent gone through the code yet but find a number of references
to trying to get an ibm patch added for it as early back as the
0.9.9x releases.<br>
<br>
Rob<br>
<br>
On 10/29/11 1:50 PM, John Bradley wrote:
<blockquote cite="mid:76DF3D5F-CC67-4E3D-B483-5C6DB14403C1@mac.com" type="cite">The JWE spec has GWC in it already.
<div><span class="Apple-style-span" style="font-family: Times; ">
<pre style="word-wrap: break-word; white-space: pre-wrap; ">A128GCM | Advanced Encryption Standard (AES) using 128 bit keys |
| | in Galois/Counter Mode, as defined in [FIPS-197] and |
| | [NIST-800-38D] |
| A256GCM | Advanced Encryption Standard (AES) using 256 bit keys |
| | in Galois/Counter Mode, as defined in [FIPS-197] and |
| | [NIST-800-38D] |</pre>
</span>
<div>I think GCM is only supported in openSSL 1.1.</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><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 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><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 moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto: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 moz-do-not-send="true" href="mailto:Axel.Nennker@telekom.de">Axel.Nennker@telekom.de</a>;
<a moz-do-not-send="true" href="mailto:jbradley@mac.com">jbradley@mac.com</a><br>
</blockquote>
<blockquote type="cite">Cc: <a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On
Behalf Of <a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:jbradley@mac.com">jbradley@mac.com</a><br>
</blockquote>
<blockquote type="cite">Cc: <a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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
[<a class="moz-txt-link-freetext" href="mailto:jbradley@mac.com">mailto: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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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">[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto: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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
</blockquote>
<blockquote type="cite"><a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
</blockquote>
<blockquote type="cite"><a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
</blockquote>
<blockquote type="cite"><a moz-do-not-send="true" 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>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div></div><br></body></html>