Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Paul and Valery, >> Either a new exchange or an untrusted stream of >> fragments. Either way, a lot of complexity for a rather moving target >> goal that we don't understand yet. I'd personally rather wait until we >> know a bit more about the direction that quantum safe protocols are >>

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Paul, > >>Adding IKE-level fragmentation to the process adds an additional place > >>that DDoS attacks can hit. > > > > We have DDoS protection mechanisms. I think it's possible to define > > IKE_SA_INIT fragmentation so that these mechanisms be still able to work. > > That would be

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

On Fri, 29 Sep 2017, Valery Smyslov wrote: Adding IKE-level fragmentation to the process adds an additional place that DDoS attacks can hit. We have DDoS protection mechanisms. I think it's possible to define IKE_SA_INIT fragmentation so that these mechanisms be still able to work.

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Michael, > > Is the main rational for not having fragmentation in IKE_SA_INIT that > > it could break the features of IKE that you list below? > > 1) we are currently working on IKE over TCP because we already know that >IKE packets (and UDP encapsulated IPsec) are not get

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Graham Bartlett (grbartle) wrote: > Is the main rational for not having fragmentation in IKE_SA_INIT that > it could break the features of IKE that you list below? 1) we are currently working on IKE over TCP because we already know that IKE packets (and UDP

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Michael Is the main rational for not having fragmentation in IKE_SA_INIT that it could break the features of IKE that you list below? The reason I ask, we’re working on the current draft and looking to implement optional fragmentation in the IKE_SA_INIT, but this would be friendly to

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Bruckert, Leonie writes: > Additionally, it would be nice to also protect the identities i.e. > to make the AUTH exchange quantum resistant. Particularly with > regard to the PPK draft which doesn’t assure this. As we discussed earlier, some kind of pseudonym system might be better for this,

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

-Ursprüngliche Nachricht- Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Scott Fluhrer (sfluhrer) Gesendet: Dienstag, 22. August 2017 16:31 An: Cen Jung Tjhai; Valery Smyslov; 'Tero Kivinen' Cc: ipsec@ietf.org Betreff: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Tero So I’m not a big fan of the interim exchange (Scott had suggested something similar). I would imagine that it’s going to decrease the tunnel setup rate on VPN GW’s. Adds at minimum another round trip, which could be >two if the QS blob isn’t correct or many more if fragmentation. It

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

> -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Cen Jung Tjhai > Sent: Tuesday, August 22, 2017 6:43 AM > To: Valery Smyslov; 'Tero Kivinen' > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2 &g

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi >> Well, that are valid reasons. However, what makes me uncomfortable is that >> this design >> looks like yet another short-term (or medium-term) solution. We already have >> draft-fluhrer-qr-ikev2 that was declared as a temporary short-term approach >> to countermeasure >> immediate

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Tero Kivinen wrote: > Daniel Van Geest writes: >> 1) QS SA Negotiation >> >> When negotiating a QS SA, it’s not enough to negotiate QS key >> agreement algorithm(s), one also has to ensure that the algorithms >> selected by the other transform types are

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

> -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen > Sent: Monday, August 14, 2017 9:05 AM > To: Michael Richardson > Cc: ipsec@ietf.org; Daniel Van Geest; Graham Bartlett (grbartle) > Subject: Re: [IPsec] Proposed method

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Michael Richardson writes: > I don't think we need to do this. > I think that unknown transform types will be ignored by compliant > implementations. Nope. It will ignore unknown transform IDs for each known transform type, but it MUST understand each transform type, and if it does not understand

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Daniel Van Geest writes: > 1) QS SA Negotiation > > When negotiating a QS SA, it’s not enough to negotiate QS key > agreement algorithm(s), one also has to ensure that the algorithms > selected by the other transform types are also QS. All of these kind of issues are really policy matters, thus

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

>>> Is the size of QSKE blob that the responder has to return to initiator >>> likely >>> to be either unknown to the initator or very different than the >>> initiator->responder direction? I believe Daniel has touched on this. But let me add more information on this specific query. There are

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

>>> The only reason that comes to my mind is that you don’t fully trust >>> QSKE. Are there any other reasons? >>I think that is one of the main reasons. Especially as we do not know >>which QSKE we are talking about. Another reason for not removing KE is potentially due to

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

On Aug 9, 2017, at 2:12 PM, Michael Richardson > wrote: I don’t find the re-use of transform 4 in this proposal, and the implicit combination of QS + non-QS algorithms, to be the most elegant, though I can understand it in the context of not

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Daniel Van Geest wrote: > transform *attributes*, but not about transforms). My point here is > that if a responder may chose any of the proposed transforms then for > the first proposal to be QS it must not contain any quantum-insecure > transforms, or

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Tero Kivinen wrote: > Actually I think it would be better NOT to change IKE_SA_INIT at all, > but instead add new exchange between the IKE_SA_INIT and IKE_AUTH. I agree. All of the DoS (cookie, etc.) defense and switch to TCP, and detection of NAT-T, etc. is in the

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Cen Jung Tjhai writes: >>And I think if the IKE_SA_INIT messages grow too large with QSKE, >>then it’s better to develop generic fragmentation mechanism for >>IKE_SA_INIT, rather than making it specific for fragmenting QSKE >>blobs. Generic mechanism would allow to reuse it in case we’ll have >>to

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Valery Smyslov writes: > It is not clear for me (and I raised this concern in Prague) why do > you use QSKE as an additional Key Exchange mechanism instead of > replacing DH KE with it? We’ve been being told by cryptographers > that conventional public key cryptography won’t provide security in >

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Sorry for the late reply. I’ve replied to where I feel I could add some more context to CJ’s reply. GB>inline On 05/08/2017, 14:29, "IPsec on behalf of Cen Jung Tjhai" wrote: Hi Paul, >>> 4. The large quantum

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Paul, >>> 4. The large quantum resistant ‘blob’ of data is only sent when it is >>> known that the peer will accept this. >>I don't understand this? You mean known by preconfiguration? That would >>make migration really difficult and introduce a flag day. It would also >>not be true for

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

​Hi Valery,   >>And I think if the IKE_SA_INIT messages grow too large with QSKE, then it’s >>better to develop >>generic fragmentation mechanism for IKE_SA_INIT, rather than making it >>specific for fragmenting >>QSKE blobs. Generic mechanism would allow to reuse it in case we’ll have to

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Graham, few comments. It is not clear for me (and I raised this concern in Prague) why do you use QSKE as an additional Key Exchange mechanism instead of replacing DH KE with it? We’ve been being told by cryptographers that conventional public key cryptography won’t provide security

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

On Thu, 3 Aug 2017, Graham Bartlett (grbartle) wrote: 1.  The IKE_AUTH exchange is protected using the quantum secure algorithms. So all attributes within the IKE exchange are protected against passive attacks, which wouldn’t be the case should the quantum resistant ‘blob’ be sent in

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Hi Scott, >> The other question about your proposed mechanism is how does it work; you >> just outline >> a way to exchange ‘quantum resistant’ blobs, and don’t say how those blobs >> actually work. >> I’m not talking about the cryptography, I’m talking about the >> authentication. For an >>

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Scott Fluhrer (sfluhrer) wrote: > EAP; frankly, I’m not that familiar with EAP, however, if EAP isn’t currently > postquantum secure, it may make sense for that protocol to be updated. EAP is a framework for a set of algorithms, some of which are are as stupid as