Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
On Mon, 4 Jul 2016, Scott Fluhrer (sfluhrer) wrote: Actually, the draft is a bolt-on to existing authentication methods; You might object "how is this different from a having a possibly global authentication key"; Because of this, it wouldn't appear to be advisable to wait for the full solution; for people who are concerned about Quantum Computers, it would be appropriate to have a short term solution. In my mind, it's OK if the short term solution doesn't address all possible scenarios; it's sufficient if it provides a way to address the immediate need for those people who are concerned. In that case, I feel we are back at making a much simpler solution of providing a key identifier that leads to an additional mixing in of SKEYSEED generation. And not add methods of ID hiding. And have something that can be tested by implementations using a shared OTP. If the people discussing this will be in Berlin, perhaps we should put this on the agenda to discuss? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
> -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, July 04, 2016 5:44 AM > To: Yoav Nir > Cc: ipsec@ietf.org; Mark McFadden > Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME > WG document > > On Sun, 3 Jul 2016, Yoav Nir wrote: > > >> 3) The Internet Draft Currently under consideration is not the best > >> starting > point as it assumes that post-quantum pre-shared keys are the preferred > solution for quantum resistance. This is not obviously the case; there are a > number of drawbacks with the suggested system: > > > > I think this misstates the problem that the draft is trying to solve. The > > draft > is not a solution to the problem of authenticating peers in a world where > adversaries have quantum computers. The draft is a solution to the problem > of authenticating peers *using pre-shared keys* in such a world. There may > be different solutions for authenticating peers with other credentials. Actually, the draft is a bolt-on to existing authentication methods; the authentication method uses is the new 'postquantum preshared keys' plus whatever IKEv2 authentication mechanism that the peers use. For example, you can use certificates to authenticate; the draft assumes there's also a shared secret that the peers have. You might object "how is this different from a having a possibly global authentication key"; the answer here is that this postquantum preshared key isn't making anything worse; if the adversary learns the ppk, they still can't break in (unless they also break the existing IKEv2 authentication mechanism). So: - An adversary can't break confidentiality unless they learn the ppk AND they can break the IKEv2 key exchange (such as with a Quantum Computer). - An adversary can't break authentication unless they learn the ppk AND they can break the existing IKEv2 authentication mechanism. Going to the broader topic, I agree that it would be preferable to have a postquantum solution that would work in all cases, without assuming a distributed secret. However, in general, this would require a postquantum key exchange, and that's the rub; we're not there yet. We have McEliece (which requires huge keys; key shares if we use it to do key exchange), we have NTRU (which some people don't trust), and they we have a large number of more recent schemes discovered in the last 5 years or so (and so haven't had enough time to be cryptographically vetted). Now, eventually we'll come up with a scheme which is both deployable and has a reasonable amount of trust; however that'll be a few years from now. On the other side, we can look at the need; no one really knows when a viable quantum computer (which can break the DH and ECDH groups that we use) will be built; the guesses that I've heard is that it might be in 10-15 years (maybe). That would make it sound like we have time, except that when a quantum computer does become available, then someone will be able to decrypt previously recorded sessions; this might mean that, in 10 years, someone might be able to decrypt encrypted traffic from today. Because of this, it wouldn't appear to be advisable to wait for the full solution; for people who are concerned about Quantum Computers, it would be appropriate to have a short term solution. In my mind, it's OK if the short term solution doesn't address all possible scenarios; it's sufficient if it provides a way to address the immediate need for those people who are concerned. > > That was not clear to me when we were asking for adoption of the > document. In one way, I have less issues with it if the document can clearly > state that is the scope of it. On the other hand, we might want to have a > discussion about the security of PSK in general, and whether the method > deserves to be obsoleted completely because of its continued weak > deployments (eg see Snowden leaks) > > > However, with my vendor hat on, I know that PSKs are used extensively > (and nobody’s asking me whether this is a good idea or not), and I have > heard that some users are beginning to ask questions about quantum > resistance.So I believe that there is a problem to solve here. > > I can see that point. As vendor it is hard to tell people not to do a certain > deployment because it is seen as "easiest". However with our IETF protocol > designer hats on, this should not be a strong argument. If we think that this WG should have a long term goal of designing a protocol that is easy to use securely, and is postquantum secure, I would agree that's a fine idea. However, that's a long term goal; I would claim that we shouldn't ignore the short term requirements as well. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
The draft provides postquantum protection to any SA, regardless of the authentication methods used. In other words, PPKs (as specified in the draft) don't replace preshred keys authentication in IKEv2, they augment any authentication method to provide postquantum security. The original title to me reads like a "new feature" instead of like a "fix for old feature". But then PaulH is wrong and this draft is a lot more then fixing just IKEv2 PSK for postquantum. Doesn't this new feature fixes IKEv2 preshared key auth? I don't think PaulH is wrong, this draft just offers a bit more. Paul Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
On Mon, 4 Jul 2016, Valery Smyslov wrote: > Isn't this kinda off-topic for the thread? I though we were first > considering "create an IKEv2 extension that mixes in the PSK" as the > simplest way to get around the "go back to IKEv1" guidance. So that was not entire clear to me from the title, but it seems you are right. Perhaps we can change the title from: Postquantum Preshared Keys for IKEv2 to: Postquantum protection for IKEv2 Preshared Keys SA's That's incorrect title. The original title is correct. The draft provides postquantum protection to any SA, regardless of the authentication methods used. In other words, PPKs (as specified in the draft) don't replace preshred keys authentication in IKEv2, they augment any authentication method to provide postquantum security. The original title to me reads like a "new feature" instead of like a "fix for old feature". But then PaulH is wrong and this draft is a lot more then fixing just IKEv2 PSK for postquantum. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
Hi Paul, Isn't this kinda off-topic for the thread? I though we were first considering "create an IKEv2 extension that mixes in the PSK" as the simplest way to get around the "go back to IKEv1" guidance. So that was not entire clear to me from the title, but it seems you are right. Perhaps we can change the title from: Postquantum Preshared Keys for IKEv2 to: Postquantum protection for IKEv2 Preshared Keys SA's That's incorrect title. The original title is correct. The draft provides postquantum protection to any SA, regardless of the authentication methods used. In other words, PPKs (as specified in the draft) don't replace preshred keys authentication in IKEv2, they augment any authentication method to provide postquantum security. The original title to me reads like a "new feature" instead of like a "fix for old feature". I think it is more like a new feature. Regards, Valery. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
On 4 Jul 2016, at 12:44 PM, Paul Wouterswrote: > On Sun, 3 Jul 2016, Yoav Nir wrote: > >>> 3) The Internet Draft Currently under consideration is not the best >>> starting point as it assumes that post-quantum pre-shared keys are the >>> preferred solution for quantum resistance. This is not obviously the case; >>> there are a number of drawbacks with the suggested system: >> >> I think this misstates the problem that the draft is trying to solve. The >> draft is not a solution to the problem of authenticating peers in a world >> where adversaries have quantum computers. The draft is a solution to the >> problem of authenticating peers *using pre-shared keys* in such a world. >> There may be different solutions for authenticating peers with other >> credentials. > > That was not clear to me when we were asking for adoption of the > document. In one way, I have less issues with it if the document > can clearly state that is the scope of it. On the other hand, we > might want to have a discussion about the security of PSK in general, > and whether the method deserves to be obsoleted completely because > of its continued weak deployments (eg see Snowden leaks) We can have that discussion. Or we can resign ourselves to designing protocols to fill requirements imposed by other people. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
On Sun, 3 Jul 2016, Paul Hoffman wrote: On 3 Jul 2016, at 11:32, Paul Wouters wrote: > On Jul 3, 2016, at 21:08, Mark McFaddenwrote: > > A number of quantum-resistant asymmetric public key algorithms have been > proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny > Diffie-Hellman. I thought NTRU was patent encumbered? Is that still the case? How about the others you mention? I agree asking CFRG for help would be a wise decision. Isn't this kinda off-topic for the thread? I though we were first considering "create an IKEv2 extension that mixes in the PSK" as the simplest way to get around the "go back to IKEv1" guidance. So that was not entire clear to me from the title, but it seems you are right. Perhaps we can change the title from: Postquantum Preshared Keys for IKEv2 to: Postquantum protection for IKEv2 Preshared Keys SA's The original title to me reads like a "new feature" instead of like a "fix for old feature". Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document
On Sun, 3 Jul 2016, Yoav Nir wrote: 3) The Internet Draft Currently under consideration is not the best starting point as it assumes that post-quantum pre-shared keys are the preferred solution for quantum resistance. This is not obviously the case; there are a number of drawbacks with the suggested system: I think this misstates the problem that the draft is trying to solve. The draft is not a solution to the problem of authenticating peers in a world where adversaries have quantum computers. The draft is a solution to the problem of authenticating peers *using pre-shared keys* in such a world. There may be different solutions for authenticating peers with other credentials. That was not clear to me when we were asking for adoption of the document. In one way, I have less issues with it if the document can clearly state that is the scope of it. On the other hand, we might want to have a discussion about the security of PSK in general, and whether the method deserves to be obsoleted completely because of its continued weak deployments (eg see Snowden leaks) However, with my vendor hat on, I know that PSKs are used extensively (and nobody’s asking me whether this is a good idea or not), and I have heard that some users are beginning to ask questions about quantum resistance.So I believe that there is a problem to solve here. I can see that point. As vendor it is hard to tell people not to do a certain deployment because it is seen as "easiest". However with our IETF protocol designer hats on, this should not be a strong argument. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec