Hi Paul, thank you for your thorough review, please see inline.
> -----Original Message----- > From: Paul Wouters via Datatracker [mailto:[email protected]] > Sent: Tuesday, November 29, 2022 12:09 AM > To: The IESG > Cc: [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected] > Subject: Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: > (with DISCUSS and > COMMENT) > > Paul Wouters has entered the following ballot position for > draft-ietf-ipsecme-ikev2-multiple-ke-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # Sec AD review of draft-ietf-ipsecme-ikev2-multiple-ke-10 > > CC @paulwouters > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > This review uses the format specified in > https://github.com/mnot/ietf-comments/ which allows > automated tools to process items (eg to produce github issers) > > Let me first apologize to Valery for not getting to review this document > earlier. He surely > reminded me enough times to do it before it landed at the IESG. No problem, I did know that you wouldn't escape this review :-) > This is a very well written document. Thanks to everyone involved. While I > have a few DISCUSS > comments, these should be easy to address or convince me why no changes are > required. Thank you. > Note to self (and Valery): draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt > needs to be updated > to support this document. It currently only supports sending one KE payload. OK. I don't think it would be difficult. > ## DISCUSS > > > ### IANA entries mentions in the Introduction ? > > Shouldn't the introduction mention this draft introduces the IKE_FOLLOWUP_KE > Exchange > and the STATE_NOT_FOUND Notify Message Type, along with additional entries to > the > (now renamed) Key Exchanges Methods registry? I'm a bit puzzled here. The introduction currently is silent about the details of the proposed extension. Do you want to add them there? Or did you mean the Abstract, (which indeed contains some details) to be augmented with more details? > ### Additional key exchanges DoS ? > > The following paragraph raised an issue for me: > ``` > If the responder selects NONE for some Additional Key Exchange types > (provided they are proposed by the initiator), then the corresponding > IKE_INTERMEDIATE exchanges MUST NOT take place. > ``` > If the initiator's local policy requires at least one Additional Key Exchange, > an attacker sending back a quick reply with only NONE replies would be a DoS. > I think similar to like the original IKE_SA_INIT, perhaps we need to give some > advise that if the local policy would lead to permanent failure, that it > should wait for other (more legitimate) responses to this IKE_SA_INIT ? As you pointed out, the situation is exactly the same as described in Section 2.4 of RFC 7296: One type of DoS attack on the initiator of an IKE SA can be avoided if the initiator takes proper care: since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the initiator's message before the genuine responder and poison the connection setup attempt. To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each response as potentially legitimate, respond to each one, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid. Since the draft adds nothing new into the negotiation mechanism in the IKE_SA_INIT, I see no need to reiterate this advice here (otherwise we may want to repeat a lot of text from base IKEv2 spec :-)). > ### ADDITIONAL_KEY_EXCHANGE > ``` > After IKE SA is created the window size may be greater than one and > multiple concurrent exchanges may be in progress, it is essential to > link the IKE_FOLLOWUP_KE exchanges together > ``` > I had some trouble figuring out why these are needed. For Child SA rekeys, > these > would not be needed, because we would have an old SPI and MSGID that would > make the > order obvious. But for adding addtional Child SA's, we have no old SPI. But > we have > a new SPI on the initiator (and then a new SPI on the responder in the > answer. Since > these are coupled by MSGID, I wonder if ADDITIONAL_KEY_EXCHANGE is really > needed? > Looking at the useful appendix examples, I realise that the IKE_FOLLOWUP_KE > exchange > does not have an SA payload so no SPI, so it makes sense to me now. Perhaps a > sentence > in the document would be useful to explain this? How about: After IKE SA is created the window size may be greater than one and multiple concurrent exchanges may be in progress, it is essential to link the IKE_FOLLOWUP_KE exchanges together and with the corresponding CREATE_CHILD_SA exchange. Due to the fact that once IKE SA is created all IKE exchanges are independent and don't have built-in means to link one with another, a new status type notification ADDITIONAL_KEY_EXCHANGE is introduced for this purpose. (feel free to edit the text). > I still do not know why not to use the SPI as value for > ADDITIONAL_KEY_EXCHANGE instead > of an opaque linking blob? The SPI is traditionally our linking blob. The opaque blob can be an SPI. Or something else, that the responder thinks better suits for this purpose. In my implementation it is the MID of the exchange containing the previous key exchange (either CREATE_CHILD_SA or IKE_FOLLOWUP_KE). > Could the IKE_FOLLOWUP_KE set the SPI value in the IKE header instead of using > a new ADDITIONAL_KEY_EXCHANGE payload and use that with the MSGID as linking > blob? Hm, we don't have a room in the IKE header for a new SPI :-) Am I missing your point? > ### State loss issue > ``` > After receiving this notification the initiator MAY start > a new CREATE_CHILD_SA exchange which may eventually be followed by > the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt. If the > initiator continues to receive STATE_NOT_FOUND notifications [...] > ``` > How could this happen? If the state was lost, eg due to reboot, there would > need to come a new IKE SA, that can then send a new CREATE_CHILD_SA. I don't > see how that could lead to another STATE_NOT_FOUND. But the paragraph then > also continues with "and delete [the] IKE SA". But this IKE SA is brand new? > I would just remove this entire paragraph as I think this cannot happen. Or > at least it is not a special case and existing abort code handles this > already. No, this is not concerned with reboots. It is concerned with the situation when it takes too long for the initiator to compute the next public key value to send to the responder (the delay may also be caused by lost packets). So, when the responder first receives the CREATE_CHILD_SA exchange and negotiates using multiple key exchanges, it expects that some IKE_FOLLOWUP_KE exchanges shortly follow (with some definition of "shortly"). So, it creates a state that would contain all the shared key computed as a result of these exchanges. But the responder cannot keep this state forever (for example, the initiator may be switched off and never send next request), so the responder have to do housekeeping and remove this state if the responder doesn't receive the next IKE_FOLLOWUP_KE exchange in a timely fashion (again, with some definition of "timely fashion"). Then consider the situation when initiator cannot make the next request within this period (either it takes too long to compute the key or some request messages were lost and the responder received the n-th retransmission). In this case the responder receives the IKE_FOLLOWUP_KE exchange, but it doesn't already have the state to which it can add this new shared key, so it responds with NO_STATE_FOUND. This is non-fatal notification, so the initiator may start all from scratch (from the CREATE_CHILD_SA exchange) in a hope that this time its performance or network conditions would be better. Does this help? > ### IKE session resumption > > Should there be a section updating RFC 5723 Section 5.1, or is the method > there > specified quantum-safe if the initial IKE SA was protected using this > document's > mechanism? See https://www.rfc-editor.org/rfc/rfc5723.html#section-5.1 > > I think the IKE resumption can work "as normal", as no KE payload is > involved in the resumption, but it would be nice if a sentence somewhere > in this document could confirm this. Yes, I agree. We didn't add anything since there is no interaction with RFC 5723 (it works "as normal"). We can add some text if you think it is needed. > Also RFC 5723 states: > ``` > The keys and cryptographic protection algorithms should be at > least 128 bits in strength. > ``` > IF we live in Grover universe, perhaps that should be 256 bits in strength? > And since > we are making things quantum safe with this document, perhaps we should then > at least > state session tickets should be 256 bits. Note if we do, then this document > must > Update: RFC 5723. Perhaps this note on 5723 can be added in the Security > Considerations > Section paragraph that talks about Grover and Shor. The recent recommendations from NIST for the safe symmetric key size went back to 128 bits, because the Grover algorithm appears to require so large amount of quantum memory, that it makes it almost impractical. Note, that the Security Considerations section of the draft says: It was previously believed that one needed to double the key length of these algorithms. However, there are a number of factors that suggest that it is quite unlikely to achieve the quadratic speed up using Grover's algorithm. According to NIST [NISTPQCFAQ], current applications can continue using AES algorithm with the minimum key length of 128 bit. > ### non-fatal NO_PROPOSAL_CHOSEN? > ``` > In this case, the responder may respond with > non-fatal error such as NO_PROPOSAL_CHOSEN notify message type. > ``` > Technically, this error is non-fatal. But in this context, wouldn't it be > fatal if the > responder insists on additional exchanges during the initial exchange and the > initiator > doesn't suppor this? It is sort of a lame duck IKE SA ? :) It is non-fatal in this context, since it is sent in the IKE_AUTH just to prevent Child SA to be created. IKE SA will be created in any case (provided no authentication issues arise). The responder has already agreed to skip additional key exchanges for the initial IKE SA (since it agreed on the proposals in the IKE_SA_INIT). But the responder doesn't want to create any Child SA without PQ protection, so it purposely makes it failed (since the initiator doesn't support Childless IKE SA, which is a "proper" way to handle this situation). Then the responder may immediately rekey IKE SA with PQ algorithms (or wait the initiator to do this). > Also the "may" responder is unclear to me. What other response could there be > and why? The responder has few choices here. It expects the initiator starts childless IKE_AUTH, but it didn't happen. First the responder may fail the IKE SA itself (e.g. by sending SYNTAX_ERROR). It will be a fatal error. Then, the responder may agree to create the Child SA, but immediately delete it (no guarantee that no data will be sent over it). The suggested method is a bit of protocol hack, but it allows to avoid creating of weak Child SA and at the same time it keeps chances that the IKE SA be upgraded to be PQ-safe. > ### misplaced text? > ``` > Note that if the initial IKE SA is used to transfer sensitive > information, then this information will not be protected using the > additional key exchanges [...] > ``` > This paragraph appears in the Section "Interaction with Childless IKE SA", > but should probably > be moved to the Security Considerations section. The Security Considerations has already some text that is related to this (the last para). The reason this text is in the "Interaction with Childless IKE SA" is to emphasize, that with the approach described in this section (Childless initial IKE SA, then rekey IKE SA with PQ algorithms) the initial IKE SA will be not PQ-safe, that may be inappropriate for some use cases. However, referencing G-IKEv2 seems to be wrong here (it has nothing to do with Childless IKE SA), so I moved the text referencing G-IKEv2 to the Security Considerations section. > ### IKE_FOLLOWUP_KE name > > I find the name IKE_FOLLOWUP_KE a little confusing, as this exchange applies > to > IKE and IPsec SA rekey negotiations. Why is it not called > FOLLOWUP_ADDITIONAL_KE ? > Or CREATE_CHILD_SA_FOLLOWUP(_KE) (a sort of bad name too but that at least > follows the > bad name from the original IKEv2 spec) If you remember, we have had some discussion in the ipsecme WG, and then you suggested that all new IKE exchanges start with IKE_ prefix. We just followed this suggestion :-) Well, I don't care much what the name is, so I rely on my co-authors on this. I only hope it won't be too long and will be easy to pronounce :-) > ### authentication ? > > ``` > This document does not address authentication since it is less urgent > at this stage. > ``` > While true, it does state that PPKs can be used. It might also want to say > that > no IKE protocol level changes would be needed for authentication. A new RFC > 7427 > Digital Signature algorithm that is quantum-safe could be defined for X.509 > and would > become available immediately without any IKEv2 level changes. So in a way, > this > issue will be addressed but no IKEv2 document is needed for that. Perhaps this > can be clarified in the draft? I'm not so sure. I'd like to avoid any speculations on this topic in this draft. For example, the following draft does make few changes to IKEv2 (or at least uses the features that are not yet standardized): https://www.ietf.org/archive/id/draft-guthrie-ipsecme-ikev2-hybrid-auth-00.txt There may also be issues with the size of AUTH and CERT payloads... > Related to this is text in the Security Considerations: > > ``` > In particular, the authenticity of the SAs established > under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA > algorithms. > ``` > This text is also incorrect as RFC 7427 allows us to use post-quantum > authentication > algorithms that have a SubjectPublicKeyInfo (SPKI) definition. There might > not be any > now, but there will presumbly be some in the future. Do you want to augment this text? Any suggestions? > ### AH > > Section 4 lists AH. Is there much point in using this document when deploying > AH? > The idea was the protect against _future_ quantum computers breaking > encryption, > not MITM style packet modification. So using AH (or ESP_NULL) with this > document > seems pointless :) I see your point. But until the AH is formally deprecated, one is free to use it :-) Note also, that the draft has another application - to be able to combine several key exchange algorithms so that the resulting key depends on all. For example, if each side trusts only its own key exchange algorithms and absolutely doesn't trust the peer's ones. This application is described in the introduction and it is orthogonal to post-quantum cryptography. So, keeping this case in mind, I'd rather keep the table as is. > And the Security Considerations kind of agree with me here: > ``` > Until quantum computers > become available there is no point in attacking the authenticity of a > connection because there are no possibilities for exploitation. > ``` I see no contradiction to my point :-) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## Comments > > ### Section 2 > > I would probably have moved the Design Criteria to a later Section or > Appendix, > after the entire protocol specification and Security Considerations. It's nice > to know the background, but this is "optional information" and shouldn't be as > much at the focus at the start of the document. (this is comment, you are fine > to disagree and leave it where it is) I don't disagree with you, but I'd like to hear from my co-authors. > ### should -> could > ``` > However, if such a requirement is > needed, [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that > should be taken to exchange huge payloads. > ``` > I think this should should be a could, because it is a draft and it isn't > even adopted yet. I don't think that is suitable for a "should" even in > lowercase. Agree. Fixed. > ### Design Criterea > > One design criteria I do not see mentioned is "limit the extra number of RTTs > as > much as possible". I do believe that was an important design criterea ? > > The "future proof" design criterea is probably better named as "not > post-quantum specific" ? Well, I'd rely on my co-authors. > ### Section 3 > > ``` > A hybrid solution, when multiple > key exchanges are performed and the calculated shared key depends on > all of them, allows us to deal with this uncertainty by combining a > classical key exchange with a post-quantum one, as well as leaving > open the possibility of multiple post-quantum key exchanges. > ``` > > This is an excellent summary sentence. It would be great to actually have this > one in the introduction :) Thank you, we'll think where to place it. > ### IKE_INTERMEDIATE "is encrypted" > ``` > The additional key exchanges are performed using > IKE_INTERMEDIATE messages; because these messages are encrypted, the > standard IKE fragmentation mechanism is available. > ``` > I think this is confusing. It is not really "because" they are encrypted that > the fragmentation mechanism "is available". Additionally, "encrypted" probably > should clarify the level of encryption - eg it would not me post-quantum safe. > And of course it does not need to be. Mabye something like: > > The additional key exchanges are performed using IKE_INTERMEDIATE messages > that follow the IKE_SA_INIT exchange. This is to allow for standard IKE > fragmentation mechanisms to be available for the potentially large > post-quantum Key Exchange algorithm payloads. The IKE_SA_INIT exchange does > not [cannot?] support fragmentation. Then how about: The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. This is to allow for standard IKE fragmentation mechanisms (which cannot be used in IKE_SA_INIT) to be available for the potentially large post-quantum Key Exchange algorithm payloads. > ### > ``` > and that hybrid key exchange is not needed. > ``` > Maybe: > > and that a hybrid key exchange containing a classic (EC)DH is no longer > needed. I'd rather to keep the text as is. My co-authors might disagree :-) > ### Section 3.1 Childless? > ``` > Following that, the IKE_AUTH exchange authenticates peers > and completes IKE SA establishment. > ``` > This made me wonder if it was required to do a Childless IKE SA. I think a > clarification is in order here. Perhaps: > > Following that, the IKE_AUTH exchange comples at normal and authenticates the > peers, completes the IKE SA establishment and when not childless, a Child SA > is > also established. I'm not sure this clarification is needed. This section is focused on IKE SA establishment, so if we go into all the details, readers may not follow the main idea. > ### Section 3.1 ASCII art > > Probably, it should be clarified here that {} means "encrypted", or point a > sentence on syntax to the explanation in RFC7296? While this is obvious to > readers of IKEv2 documents, this document has not actually stated that this is > the meaning. Additionally, perhaps introduce a {{foo}} that means encrypted > safely for classic and quantum ? We can add a sentence that diagrams follow RFC 7296 notation (although to be frank, I don't remember which other IKE extension documents have this text). What my co-authors think? And with regard to {{foo}} - I think here we may confuse readers since the draft explicitly allows combining non-PQ key exchange algorithms (in which case we cannot claim the result is quantum safe). > ### duplicated algorithms > > ``` > MUST NOT contain duplicated algorithms > ``` > But it goes on saying this _can_ be possible, if the algorithm properties are > the same, so this sentence needs to reflect that to avoid misimplementation. > Maybe: > > MUST NOT contain duplicated algorithms with identical attributes I suggest then: MUST NOT contain duplicated algorithms (those with identical Transform ID and attributes) since "algorithm" != "transform" > ### Section 3.2.1. MUST stop SA > ``` > the initiator should log the > error and MUST stop creating the SA or delete the SA if it is a > rekey. > ``` > > There is ambiguity here on the "delete the SA if it is a rekey". I think you > mean to say to stop creating or delete the SA being negotiated, and not to > delete the SA that was attempted to be rekeyed. How about the simpler: > > the initiator should log the error and MUST abort the exchange with a > permanent > error. No, the text is correct (and we suggest to delete the SA that was attempted to be rekeyed). The reason - the initiator has received invalid message from the responder. It cannot abort the exchange since the exchange has already completed. This is similar to the situation in IKEv2 when the initiator sends, for example, a single proposal to use AES-GCM, and the responder responds with Chacha-Poly (which was not proposed at all). The only thing the initiator can do in this case - delete the SA. I think that the text may be clarified a bit. How about? the initiator should log the error and MUST treat this situation as a permanent error for the IKE SA the invalid response was received over. If this SA is fully authenticated at this point, then the initiator MUST delete it by sending a Delete payload. > ### Section 3.2.1 IKE_INTERMEDIATE > ``` > then the corresponding IKE_INTERMEDIATE exchanges MUST NOT take place. > ``` > You are already then clarifying this statement, but perhaps to avoid > misimplementing, rewrite this to: > > then the corresponding Additional Key Exchange(s) in the IKE_INTERMEDIATE > exchanges MUST NOT take place. If there is no Additional Key Exchange left to > negotiate, this could mean that there is no more need to perform any > IKE_INTERMEDIATE exchanges. [and remove the following paragraph completely] I'd rather to use your text partially: then the corresponding Additional Key Exchange(s) in the IKE_INTERMEDIATE exchanges MUST NOT take place. This is correct clarification. The rest of your text is not completely correct - there may be needs to perform IKE_INTERMEDIATE for purposes other than additional KE. I'll left the rest of the para as is. > ### Section 3.2.2 > ``` > The other keying materials SK_d, SK_ai, SK_ar, SK_ei, > SK_er, SK_pi, SK_pr are updated as: > > [...] > ``` > Why not say: The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er, > SK_pi, SK_pr are generated from the SKEYSEED(n) as per RFC 7296. No objection. > ### Section 3.2.3 > ``` > This exchange is the > standard IKE exchange, except that the initiator and responder signed > octets are modified as described in [RFC9242]. > ``` > Instead of "modified", which might mislead the reader into thinking this > documents "modifies" that process, I would say: > > This exchange is the standard IKE exchange as described in [RFC7296] and > [RFC9242]. How about This exchange is the standard IKE exchange as described in [RFC7296] with the modification of AUTH payload calculation described in [RFC9242]. This way we emphasize that the exchange is not completely standard :-) > ### Section 3.2.4 missed rename > ``` > the peers may optionally perform a Diffie-Hellman key exchange > ``` > Should this not also be renamed into: perform an additional Key Exchange > Method Good catch. But I think the correct text is: the peers may optionally perform a key exchange to add a fresh entropy into the session keys. We here talk about generic key exchange (single or multiple). We add a notice about a possibility to perform multiple (i.e. additional) key exchanges a couple of sentences later. > ### Section 3.2.4 Simultanious rekey > ``` > the initiator of this exchange just stops the > rekeying process and it MUST NOT initiate the IKE_FOLLOWUP_KE > exchange. > ``` > should this clarify with: and MUST delete the state and MUST NOT send a > Delete/notify ? I don't think so. When initiator stops rekeying process, it obviously deletes associated state. And there is no point to send Delete, since the SA is not created yet (it would be created only when all IKE_FOLLOWUP_KE exchanges are complete). > ### Section 3.2.5 Childless IKE SA > > This section explains how to use establish Child SAs without using the > IKE_INTERMEDIATE exchange. > > I guess I would prefer that there are not two ways to do something, as IKEv2 > is > already complex enough. But I guess the infrastructure needed for rekeying > causes this additional method to creep in whether we want it or not. There was a request from some folks who were concerned with the possibility of DoS attack due to exchange of large amount of information with unauthenticated peer. So we added the possibility to avoid this concern. > ### I did? > ``` > Thanks to Paul Wouters for reviewing the document. > ``` > I have no memory of this. Or was this pro-actively added? More serious, I > guess > I did review this a long long time ago when the document looked very different > :) Anyway, I think that your thorough review definitely deserves this text to persist :-) > ### Example is a bit contrived :) > ``` > Transform AKE1 (ID = PQ_KEM_1) > Transform AKE1 (ID = PQ_KEM_2) > Transform AKE1 (ID = NONE) > Transform AKE2 (ID = PQ_KEM_3) > Transform AKE2 (ID = PQ_KEM_4) > Transform AKE2 (ID = NONE) > Transform AKE3 (ID = PQ_KEM_5) > Transform AKE3 (ID = PQ_KEM_6) > Transform AKE3 (ID = NONE) > ``` > I understand this is just an example to show the processing, but it would be a > little odd that both the order of (1|2) before (3|4) before (5|6) would matter > if these sets are all themselves optional - they are "optional requirements" ? > :) We can shuffle them :-) But will this help readers? > ### Sending post-quantum proposals and policies in KE payload only > > This solution was rejected because of a downgrade attack. Note though, that a > new notify payload of 'I_TRIED_POST_QUANTUM_FIRST' could be sent and the > attacker would have been caught in IKE_AUTH by the responder seeing this > notify > but never having seen the PQ KE payloads. (not saying we should abandon this > doc and go back to this proposal :) As far as I remember, this approach also didn't rely on IKE fragmentation, so it introduced an alternative mechanism to deal with large public keys in the IKE_SA_INIT exchange. My co-authors may have better recollections. > ### NITS > ``` > needs to be integrated into IPsec protocol > ``` > > should be "into the IPsec protocol" Fixed. > ``` > Currently, there does not exist a post-quantum key > exchange that is trusted at the level that (EC)DH is trusted > against conventional (non-quantum) adversaries. A hybrid post- > quantum algorithm to be introduced next to well-established > primitives, since the overall security is at least as strong as > each individual primitive. > ``` > > I found this hard to read. How about: > > There is currently no post-quantum key exchange that is trusted at > the level that (EC)DH is trusted for against conventional > (non-quantum) > adversaries. A hybrid post-quantum algorithm to be introduced along > with the well-established primitives addresses this concern, since the > overall security is at least as strong as each individual primitive. Will use this text unless my co-authors disagree, thank you. > ``` > A passive attacker can > eavesdrop on IPsec communication today and decrypt it once a > quantum computer is available in the future. > ``` > > I think "eavesdrop" can be misinterpreted here. How about: > > A passive attacker can store all monitored encrypted IPsec > communication > today and decrypt it once a quantum computer is available in the > future. Will use this text unless my co-authors disagree, thank you. > ``` > This is a very > serious attack for which we do not have a solution. > ``` > > We have a solution, this document. It reads a bit as if this is undefendable > now. > > How about: > > This attack can have serious consequences that won't be visible for > years to come. This document presents a defense against this serious > attack. OK. > ``` > Nonetheless, it is possible to > combine this post-quantum algorithm with a FIPS complaint key > establishment method so that the overall design is FIPS > compliant > ``` > > I would change "is FIPS compliant" to "remains FIPS compliant" OK. > ``` > The fact, that > ``` > Remove the comma Done. > ``` > but this behavior is already specified > ``` > > change to "but that this behaviour ....." I see no difference, but I have to trust you here :-) > ``` > The responder performs negotiation > ``` > > The responder performs the negotiation (added "the") My bad. Fixed. > ``` > rekeying them and rekeying IKE SA itself. > ``` > change to: rekeying these and rekeying the IKE SA itself. OK. > ``` > Its Exchange Type is 44. > ``` > change to: Its Exchange Type value is 44. OK. > ``` > After IKE SA is created the window size > ``` > After an IKE SA is [...] Done. > ``` > Its Notify Message Type is 16441 > ``` > Its Notify Message Type value is 16441 OK. > ``` > that would allow linking current exchange > ``` > that would allow linkinng the current exchange My bad. Fixed. > ``` > When rekeying IKE SA or Child SA > ``` > When rekeying the IKE SA or [the] Child SA Ditto. > ``` > multiple key exchanges using post-quantum algorithm can be composed > ``` > using a post-quantum algorithm Ditto :-) > ``` > Simply increasing the key length can dwarfed this attack. ???? > ``` > > ``` > IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange > Payloads > ``` > Note this "Payloads" word is not rendered in bold like the rest of this text I believe you mean HTML output? I think we'll try to sort this out with the RFC Editor (from what I was told they use different tools to render I-Ds and RFCs). > ``` > the responder decides not to perform the additional key exchange. > ``` > > "require" instead of "perform" ? I think "perform" is correct here. It is responder who decides here, so it just decides not to do them. > ``` > Both peers then computes > ``` > Both peers then compute (no s) Typo, fixed. Thank you! The updated PR can be seen at: https://github.com/post-quantum/ietf-pq-ikev2/pull/22 Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
