[Openid-specs-ab] Encryption

Mon Oct 31 20:19:42 UTC 2011

On Mon, Oct 31, 2011 at 13:16, John Bradley <ve7jtb at ve7jtb.com> wrote:
> The more options the more likely people will get it wrong.
>
> I could live with SHA256 being the default KDF hash and SHA512 being used for any key over 256bits.
> Though it is debatable if changing the KDF hash is more of a performance issue or a security one.

This is quite easy to specify. Use the same hash for everything, and
make sure the hash specification is implied by the choice of cipher.

>
> Again for encryption keys SHA256 for keys up to 256 bits and SHA512 for keys over 256bits.
>
> Normally you are the one arguing for simplicity not me:)
>
> Thought needs to go into this and some tradeoffs selected.
>
> We could also consider including a public seed for the KDF in the envelope to vary signing and integrity keys derived from a static secret.
> Perhaps useful but an
>
> We are actually going to need a KDF anyway to go from a ECDH-ES negotiated key to a 256bit (or other length) key for bulk encryption.
>
> John
>
>
>
> On 2011-10-31, at 4:42 PM, Breno de Medeiros wrote:
>
>> On Mon, Oct 31, 2011 at 11:02, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> I am not opposed to it.
>>>
>>> However there are multiple details that need to be sorted out.
>>>
>>> If we are going that far, you probably don't want to use the same key for
>>> encrypting and integrity.
>>>
>>> That would argue for a KDF to be used to crate multiple keys from a master.
>>>
>>> Not hard ConcatKDF would work specifying different use strings.
>>>
>>> Though that may not be available packaged everywhere it is easy enough to
>>> make one if you have SHA256.
>>>
>>> This opens questions of specifying KDF
>>> Specifying hash for KDF (some default to SHA1 and others SHA256)
>>>
>>> Specifying the integrity HMAC alg.
>>>
>>> So complexity can get out of control.
>>>
>>> I think we could do something like say always:
>>> 1. concatKDF with a MAC of SHA256
>>> 2 "Encrypt" as the U input  for encryption key
>>> 3 "Integrity" as the U input for the integrity key
>>> 4 The HMAC is SHA256
>>> 5 The HMAC is calculated over the base64url encoded envelope, key wrap, and
>>> message when directly concatenated together in that order.
>>> 6 the base64url encoded output is prepended with a period and appended to
>>> the first three segments to form a JWE.
>>
>> At the very least we need to specify a companion MAC algorithm for
>> each encryption scheme. For instance, if someone is using a 512-bit
>> encryption key (conceivably in the future that will happen) the MAC
>> should use a 512-bit key as well. I am fine if the coupling of
>> encryption and mac is hard, i.e., specifying the encryption algorithm
>> automatically specifies the MAC algorithm. But having a single MAC
>> algorithm for all ciphers doesn't work.
>>
>> The same goes for the hash algorithm in the KDF.
>>
>>>
>>> That adds 13 bytes to each JWE so that is not an issue.
>>>
>>> While for us it may be nice to have lots of knobs to fiddle with, we should
>>> pick one way to add integrity to keep it simple for developers.
>>>
>>> It will add some complexity though arguably necessary if you want privacy &
>>> integrity.
>>> This is new functionality over John Panzer's proposal.
>>>
>>> I am good with documenting this proposal if you are:)
>>>
>>> John B.
>>> On 2011-10-31, at 2:07 PM, Breno de Medeiros wrote:
>>>
>>> On Mon, Oct 31, 2011 at 10:03, John Bradley <jbradley at mac.com> wrote:
>>>
>>> Is encryption with integrity better?  Yes.
>>>
>>> Without AES GCM being available in common libraries we need to force a
>>> composite operation doing both encryption and HMAC.
>>>
>>> The additional cost is negligible.
>>>
>>>
>>> That is arguably not necessary if the thing you are encrypting is already
>>> signed. (as long as you don't leave your implementation open to a padding
>>> oracle attack)
>>>
>>> That happens at a different layer. It's basic rule-of-thumb in
>>> cryptography design that having security provide by loosely coupled
>>> layers that moreover are designed for independent re-use is risky and
>>> likely to introduce vulnerabilities in unanticipated (but valid) use
>>> cases.
>>>
>>>
>>> There is a fair argument for forcing HMAC if not using GCM or an equivalent.
>>>  It however adds complexity and likely forces us to add an additional
>>> segment.
>>>
>>> Envelope.wraped_key.content.HMAC
>>>
>>> That's not optional complexity in my view.
>>>
>>>
>>> You probably want the HMAC to be over all three proceeding elements, that is
>>> why I put it on the end.
>>>
>>> That is too big a change to get in before the upcoming IETF meeting though
>>> we should probably start that discussion.
>>>
>>> The alternative is getting GWC into a shipping version of openssl and other
>>> libraries.  (I think bouncy castle is OK)
>>>
>>> John
>>>
>>> On 2011-10-31, at 1:50 PM, Breno de Medeiros wrote:
>>>
>>> I remember repeatedly arguing that non-mac'ed symmetric encryption was
>>>
>>> not useful and that the JWE spec should _not_ specify how to do that.
>>>
>>> On Sat, Oct 29, 2011 at 10:26, Mike Jones <Michael.Jones at microsoft.com>
>>> wrote:
>>>
>>> I don't have a specific patch proposal at this time.  Nat or John or Axel
>>> (or any of the rest of you!), if any of you are able to help Rob add GCM
>>> support to the PHP release in the short term, that could be a huge win.
>>>
>>>                                -- Mike
>>>
>>> -----Original Message-----
>>>
>>> From: Rob Richards [mailto:rrichards at cdatazone.org]
>>>
>>> Sent: Saturday, October 29, 2011 3:17 AM
>>>
>>> To: Mike Jones
>>>
>>> Cc: Anthony Nadalin; Axel.Nennker at telekom.de; jbradley at mac.com;
>>> openid-specs-ab at lists.openid.net
>>>
>>> Subject: Re: [Openid-specs-ab] Encryption
>>>
>>> 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/HowToBr
>>>
>>> eakXMLenc.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/23190153
>>>
>>> 2
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --Breno
>>>
>>> _______________________________________________
>>>
>>> Openid-specs-ab mailing list
>>>
>>> Openid-specs-ab at lists.openid.net
>>>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>>
>>>
>>> --
>>> --Breno
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>>
>>
>> --
>> --Breno
>
>

-- 
--Breno