[IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Filename: draft-fluhrer-qr-ikev2-02.txt Pages : 12 Date: 2016-08-04 Abstract: This document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: The trick to that is to add a new column to the IANA table https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 That's the first of two tricks: the second is getting agreement about the rules for the values in that column. It seems like there is still disagreement in the crypto community about how susceptible different algorithms and modes are to quantum. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
Paul Hoffman writes: > On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: > > > The trick to that is to add a new column to the IANA table > > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 > > That's the first of two tricks: the second is getting agreement about > the rules for the values in that column. It seems like there is still > disagreement in the crypto community about how susceptible different > algorithms and modes are to quantum. As an IANA expert, I am not that happy adding yet another column to that table. The ESP/IKEv2 reference columns already seem to make enough confusion for people :-) Also I think it is bad idea to list which ciphers are quantum computing safe, as I have no idea whether RC5 or Blowfish are really in that category, even when they do have long keys... It might be better to list ciphers which we consider not to be safe, i.e., explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using 128-bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not PRF_AES_CBC). Also this is something we might want to add to the rfc4307bis provided we can agree on the text before it goes forward. I.e. I do not think the RFC4307bis should wait for the text, as we can add it the QR document also, but if we can agree on that now, then we can add this kind of warning to rfc4307bis too. That text could be something like this: Quantum computers might able to perform Grover's algorithm; that effectively halves the size of a symmetric key. Because of this, to provide 128-bit security even when we have quantum computers, the symmetric algorithm keys needs to have least 256 bits of entropy. Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys always, they cannot use longer keys, so the text saying "even though they can use larger keys" is wrong, as those versions cannot use longer keys. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
> -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Monday, August 08, 2016 9:15 AM > To: Paul Hoffman > Cc: Yaron Sheffer; ipsec@ietf.org; Scott Fluhrer (sfluhrer) > Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt > > Paul Hoffman writes: > > On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: > > > > > The trick to that is to add a new column to the IANA table > > > https://www.iana.org/assignments/ikev2-parameters/ikev2- > parameters.x > > > html#ikev2-parameters-5 > > > > That's the first of two tricks: the second is getting agreement about > > the rules for the values in that column. It seems like there is still > > disagreement in the crypto community about how susceptible different > > algorithms and modes are to quantum. > > As an IANA expert, I am not that happy adding yet another column to that > table. The ESP/IKEv2 reference columns already seem to make enough > confusion for people :-) On the other hand, we need to give people some guidance somehow... > > Also I think it is bad idea to list which ciphers are quantum computing safe, > as > I have no idea whether RC5 or Blowfish are really in that category, even > when they do have long keys... There's no known Quantum attack against either (assuming long keys), and so they're in the same category as AES-256. > > It might be better to list ciphers which we consider not to be safe, i.e., > explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using 128- > bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not > PRF_AES_CBC). That makes a lot of sense; ultimately, we don't really know which ones are strong against Quantum Computers (then again, we really don't know which ones are strong against conventional computers using undiscovered attacks :-); we do know some are likely weak. > > Also this is something we might want to add to the rfc4307bis provided we > can agree on the text before it goes forward. I.e. I do not think the > RFC4307bis should wait for the text, as we can add it the QR document also, > but if we can agree on that now, then we can add this kind of warning to > rfc4307bis too. That text could be something like > this: > >Quantum computers might able to perform Grover's algorithm; that >effectively halves the size of a symmetric key. Because of this, to >provide 128-bit security even when we have quantum computers, the >symmetric algorithm keys needs to have least 256 bits of entropy. > > Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys > always, they cannot use longer keys, so the text saying "even though they > can use larger keys" is wrong, as those versions cannot use longer keys. Actually, if you look through the definitions of the transforms that IANA points to, RFC4434 and RFC4615, the transform can take as input a "key" longer than 128 bits. Yes, if you look inside the definition of the transform, you see that they transform the arbitrary-length "key" into a 128 bit one; people quite often don't look into the innards of their crypto (nor should they have to). > -- > kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
Scott Fluhrer (sfluhrer) writes: > > Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys > > always, they cannot use longer keys, so the text saying "even though they > > can use larger keys" is wrong, as those versions cannot use longer keys. > > Actually, if you look through the definitions of the transforms that > IANA points to, RFC4434 and RFC4615, the transform can take as input > a "key" longer than 128 bits. Yes, if you look inside the > definition of the transform, you see that they transform the > arbitrary-length "key" into a 128 bit one; people quite often don't > look into the innards of their crypto (nor should they have to). Yes, as PRF they can take arbitrary long keys, but the AES is always using 128-bit keys. So both of those are true in a way. For encryption algorithms you can use the key length attribute to specify key length for the AES, but for the PRF or INTEG you cannot, instead they use fixed length key for AES. The original version of the AES-XCBC-PRF-128 specified in the RFC3664 did require the exactly 128-bit key for the PRF use also, but this caused problems as in IKEv2 we want to use PRF on the nonces, and the shared secret, thus requiring them to be 128-bits caused problems. Because of this RFC4434 was done so that it allows arbitrary sized keying material but the PRF still has security of 128-bit... I.e. the prehashing done to feed the PRF key to the AES is just to allow any sized material, and using longer PRF key does not increase the security. So at least separate the "PRF key" and "AES key" in the text, so it is clear which text we are refering. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
On 9 Aug 2016, at 5:44, Scott Fluhrer (sfluhrer) wrote: -Original Message- From: Tero Kivinen [mailto:kivi...@iki.fi] Sent: Monday, August 08, 2016 9:15 AM To: Paul Hoffman Cc: Yaron Sheffer; ipsec@ietf.org; Scott Fluhrer (sfluhrer) Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt Paul Hoffman writes: On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: The trick to that is to add a new column to the IANA table https://www.iana.org/assignments/ikev2-parameters/ikev2- parameters.x html#ikev2-parameters-5 That's the first of two tricks: the second is getting agreement about the rules for the values in that column. It seems like there is still disagreement in the crypto community about how susceptible different algorithms and modes are to quantum. As an IANA expert, I am not that happy adding yet another column to that table. The ESP/IKEv2 reference columns already seem to make enough confusion for people :-) On the other hand, we need to give people some guidance somehow... Do we? Who is "we"? Why is "our" guidance any better than what they get from their own experts, particularly if "our" guidance gets ossified in an IANA registry or RFCs that are updated slowly? Also I think it is bad idea to list which ciphers are quantum computing safe, as I have no idea whether RC5 or Blowfish are really in that category, even when they do have long keys... There's no known Quantum attack against either (assuming long keys), and so they're in the same category as AES-256. That would be better stated as "There's currently no known..." It might be better to list ciphers which we consider not to be safe, i.e., explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using 128- bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not PRF_AES_CBC). That makes a lot of sense; ultimately, we don't really know which ones are strong against Quantum Computers (then again, we really don't know which ones are strong against conventional computers using undiscovered attacks :-); we do know some are likely weak. Exactly. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
Hi, On the other hand, we need to give people some guidance somehow... Do we? Who is "we"? Why is "our" guidance any better than what they get from their own experts, particularly if "our" guidance gets ossified in an IANA registry or RFCs that are updated slowly? Instead of listing QR-secure (or insecure) symmetric algorithms it's probably better to give some generic advice of selecting symmetric crypto in presense of Quantum Computers. For example (I stole the text from http://www.pqcrypto.eu.org/docs/initial-recommendations.pdf): Symmetric systems are usually not affected by Shor's algorithm, but they are affected by Grover's algorithm. Under Grover's attack, the best security a key of length n can offer is 2^(n/2), so AES-128 offers only 2^64 post-quantum security. This document recommends using algorithms with 256-bit keys to achieve 2^128 post-quantum security. There's no known Quantum attack against either (assuming long keys), and so they're in the same category as AES-256. That would be better stated as "There's currently no known..." Exactly. --Paul Hoffman Regards, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
> -Original Message- > From: Valery Smyslov [mailto:sva...@gmail.com] > Sent: Thursday, August 11, 2016 2:13 AM > To: Paul Hoffman; Scott Fluhrer (sfluhrer) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt > > Hi, > > >> On the other hand, we need to give people some guidance somehow... > > > > Do we? Who is "we"? Why is "our" guidance any better than what they > > get from their own experts, particularly if "our" guidance gets > > ossified in an IANA registry or RFCs that are updated slowly? > > Instead of listing QR-secure (or insecure) symmetric algorithms it's probably > better to give some generic advice of selecting symmetric crypto in presense > of Quantum Computers. > > For example (I stole the text from http://www.pqcrypto.eu.org/docs/initial- > recommendations.pdf): > > Symmetric systems are usually not affected by Shor's algorithm, but they are > affected by Grover's algorithm. Under Grover's attack, the best security a > key of length n can offer is 2^(n/2), so AES-128 offers only 2^64 post- > quantum security. This document recommends using algorithms with 256-bit > keys to achieve 2^128 post-quantum security. I'll steal this text in the next version (along with a note that, while the PRFs PRF_AES128_XCBC and PRF_AES128_CMAC do accept keys larger than 128 bits, they internally convert them to 128 bit values, and hence should be considered as 128 bit algorithms). > > >> There's no known Quantum attack against either (assuming long keys), > >> and so they're in the same category as AES-256. > > > > That would be better stated as "There's currently no known..." > > Exactly. > > > --Paul Hoffman > > Regards, > Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
