Hi Valery, Thank you for the comments, pls see my reply in line below From: Valery Smyslov <smyslov.i...@gmail.com> Sent: Wednesday, November 6, 2024 12:31 AM To: Jun Hu (Nokia) <jun...@nokia.com>; 'Wang Guilin' <wang.gui...@huawei.com>; 'Daniel Van Geest' <daniel.vange...@cryptonext-security.com>; 'Scott Fluhrer (sfluhrer)' <sfluh...@cisco.com>; 'tirumal reddy' <kond...@gmail.com> Cc: 'ipsec' <ipsec@ietf.org>; 'Wang Guilin' <wang.gui...@huawei.com> Subject: RE: [IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi, I do not have strong opinion regarding type-1 (composite signatures) vs type-2 (non-composite signatures). But as it was already mentioned, if we support non-composite signatures, then we in fact support both. And if we support type-2 (non-composite), then I believe that RFC 4739 approach is better, than what is proposed in the draft. 1. It behaves much better on lossy networks. This is because IKE fragmentation doesn’t allow to ack individual fragments. If any fragment is lost, the whole message is retransmitted. For this reason it is desirable to keep the number of fragments small. The draft currently suggests to send a single large IKE_AUTH message, that will be resulted in the more fragments, thus more probability for the need to retransmit it. With RFC 4739 several smaller IKE_AUTH messages are sent, each is individually acknowledged. The total size of the data sent will be a bit larger, than in case of single message, but this is insignificant comparing to the size of PQ signatures. Thus, I think that the need for multiple IKE_AUTH exchanges is not a drawback (as listed below), instead this is an advantage. And note, that IKE_AUTH is already multi-exchange, thus the need to extend it with more additional exchanges is easy to implement. [HJ] ML-DSA signature (2k-4kB) and certificate (2k-3kB) alone are already quite big, so even you only use ML-DSA in one IKE_AUTH packet, it almost for sure already be fragmented; plus if we think current IKEv2 fragmentation mechanism has such limitation, then shouldn’t we try to fix IKEv2 fragmentation instead? Since that limitation is a general issue, not just for this case. 1. In case of misconfiguration the RFC 4739 approach provides faster detection and reduces unnecessary resource consumption on initiator. With the approach in the draft the initiator have to sign with all signatures and then send the message. The responder will check them one by one and in case one of them fails (e.g. due to misconfiguration), there is no point to verify the rest. It means that the initiator spent its resources in vain for generating them. Note also, that with of RFC 4739 the responder immediately sends AUTHENTICATION_FAILED in this situation, thus the rest of IKE_AUTH exchanges do not take place and the initiator gets quick indication that something is wrong. [HJ] there is also case if we use RFC4739 where first AUTH exchange succeed but 2nd one fails, I don’t see huge difference 1. As a consequence of the previous consideration, the RFC 4739 approach provides better defense against DoS attacks (with some modifications). A malicious initiator may send invalid signature in the AUTH payload (e.g. just garbage), forcing the responder to spend resources to check it. It costs nothing to the initiator, but the responder has to receive the whole (large) message, buffer it, decrypt it, parse it, start verifying signature (a clever attacker would put the most resource-consuming signature first) only to drop the message. If the signatures are sent one by one in separate IKE_AUTH exchanges, and the responder has an ability to indicate the preferred order (not currently in RCC 4739, but can be added), then it would start with the smallest and easy to verify one, saving resources in case it fails. [HJ] DoS attack in this conext is not cheap, since IKEv2 already have multiple mechanisms to prevent DoS attack during IKE_SA_INIT/key-exchange, like cookie or puzzle; if attacker could reach IKE_AUTH phase after all those mechanisms, it already used quite some compute resources, especially in case of multiple key exchange case. 1. I don’t buy the argument that an additional logic is needed to bind two signatures together. They both operate on the same data, that includes random values from both sides. Thus I think that both are bound to the exchange. Am I missing something? [HJ] I think this is related to the security concern of stripping attack as described in draft-ietf-lamps-pq-composite-sigs 1. And finally, I fail to see that the draft provides a single solution for both type-1 and type-2 approaches. It seems to me that the AUTH payload processing for type-2 (non-composite) will be very different, since there should be some internal formatting to separate the signatures (or perhaps I’m missing something, the draft currently has absolutely no details on this). [HJ] the AUTH payload generation in both type-1 and type-2 are same procedure as described in 4.2.1 of draft-ietf-lamps-pq-composite-sigs, in case of type-2, step-3 is skipped, I could put more text to clarify it Lastly less round-trips is always better than more 😊 Regards, Valery. From: Jun Hu (Nokia) <jun.hu=40nokia....@dmarc.ietf.org<mailto:jun.hu=40nokia....@dmarc.ietf.org>> Sent: Tuesday, November 5, 2024 9:15 PM To: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org<mailto:Wang.Guilin=40huawei....@dmarc.ietf.org>>; Daniel Van Geest <daniel.vangeest=40cryptonext-security....@dmarc.ietf.org<mailto:daniel.vangeest=40cryptonext-security....@dmarc.ietf.org>>; Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org<mailto:sfluhrer=40cisco....@dmarc.ietf.org>>; tirumal reddy <kond...@gmail.com<mailto:kond...@gmail.com>> Cc: ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>>; Wang Guilin <wang.gui...@huawei.com<mailto:wang.gui...@huawei.com>> Subject: [IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth Thanks all for your comments. Let me try to address your comments in one reply 1. Do we need to address both type-1 and type-2? I do think we need to address both because it is not entirely up to IPsec system to decide which type to use, it is also depends on the CA, and I don’t expect all CA will take same approach, and I also don’t expect CA could quickly change from one type to another (e.g. do type-2 first, and change to type-1 in short amount of time) 2. regarding security of using lamps composite signatures for type-2, I have asked John Grey (who is one author of draft-ietf-lamps-pq-composite-sigs) to take a look; the main concern that if attacker could get signature from individual component key, but my opinion is that it is ok in this context, as long as we add some requirements and clarification like following: a. the private key used in type-2 must be dedicated to IKEv2 hybrid authentication; they can’t be used to sign anything else, not even for induvial authentication; e.g. RSA key in hybrid auth can only be used for hybrid authentication, it can’t even be used to generate a RSA only AUTH payload. b. this is already in draft, but we could mandate the two certificates must have RelatedCertificate extension as specified in draft-ietf-lamps-cert-binding-for-multi-auth, so that two certificates are indeed issued in pairs for same end-entity 3. regarding using two AUTH payloads for type-2, I don’t think that’s simpler; first of all,, AFAIK, IKEv2 never support more than one AUTH payload, support multiple AUTH payloads break that and also requires additional logic; plus multiple AUTH payloads means additional encapsulation overhead 4. regarding why not using RFC4739, following are the reasons: a. save on round-trip since if using hybrid auth with hybrid key exchange (very likely), the total amount of exchange will be quite high b. with setup-2, we will need addition logic to bind two key/signature together if using rfc4739 c. trying to use a single solution for both type-1 and type-2 5. regarding draft-reddy-ipsecme-ikev2-pqc-auth, my draft is about hybrid authentication while my understanding of draft-reddy-ipsecme-ikev2-pqc-auth is about using ML-DSA/SLH-DSA as single auth, so they are addressing different problem From: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org<mailto:Wang.Guilin=40huawei....@dmarc.ietf.org>> Sent: Tuesday, November 5, 2024 5:58 PM To: Daniel Van Geest <daniel.vangeest=40cryptonext-security....@dmarc.ietf.org<mailto:daniel.vangeest=40cryptonext-security....@dmarc.ietf.org>>; Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org<mailto:sfluhrer=40cisco....@dmarc.ietf.org>>; tirumal reddy <kond...@gmail.com<mailto:kond...@gmail.com>> Cc: ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>>; Wang Guilin <wang.gui...@huawei.com<mailto:wang.gui...@huawei.com>> Subject: [IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Type-1 is more compatible with composite-signature in lamps. However, Type-2 is more flexible. Say, we have 4 traditional signature algorithms and 3 PQ signature algorithms. Then, we just need in total 7 algorithm IDs to denote these algorithms and all possible combinations of them. However, for Type-1, we need another 12 algorithm IDs just for all PQ/T combinations (not mentioning potential combinations of 3 or more algorithms). Also, the improving suugestions from Scott are interesting. Guilin From:Daniel Van Geest <daniel.vangeest=40cryptonext-security....@dmarc.ietf.org<mailto:daniel.vangeest=40cryptonext-security....@dmarc.ietf.org>> To:Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org<mailto:sfluhrer=40cisco....@dmarc.ietf.org>>;tirumal reddy <kond...@gmail.com<mailto:kond...@gmail.com>> Cc:ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>> Date:2024-11-05 17:28:00 Subject:[IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth And if the WG decides it wants to use Type-2 as specified in draft-hu-ipsecme-pqt-hybrid-auth, we should also advise LAMPS that we intend to abuse their composite signatures construction by reusing private keys within a composite signature and stand-alone. Perhaps the non-separability concerns aren't an issue in IKEv2 because the nonces make the signed content different for every signature. Daniel On 2024-11-05 4:31 p.m., Scott Fluhrer (sfluhrer) wrote: If we (as a working group) decide we want to use Type-1, we should advise the LAMPS working group that we intend to use their proposal. They provide a tool that we (IPSecME) uses; they need to know that there is demand for such a tool. From: tirumal reddy<kond...@gmail.com><mailto:kond...@gmail.com> Sent: Tuesday, November 5, 2024 9:17 AM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com><mailto:sfluh...@cisco.com> Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> Subject: Re: [IPsec] draft-hu-ipsecme-pqt-hybrid-auth I prefer Type-1 over Type-2, it seems more complicated to manage multiple certificates and the possibility of a downgrade attack . -Tiru On Tue, 5 Nov 2024 at 15:40, Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: While I support the goals of this draft, I do not believe that the methods proposed are the most effective. It tries to merge Type-1 (certificates that include both classical and PQ keys) and Type-2 (two separate certificates) methods of providing public keys, however I believe it would be cleaner to keep them separate. For Type-1, if we use the ietf-lamps-pq-composite-sigs certificate format, then it is easy. That defines a new signature algorithm (which internally consists of a classical signature and a PQ signature pasted together, but we can ignore the internal details). We can use that as the signature method within the Auth payload, and hence the only changes we need to make to IKE is to recognize this new signature method. For Type-2 (multiple certificates), we need to request multiple certificates (which you do with the current proposal). However, it would be cleaner i(IMHO) if the other side just provided multiple CERT payloads and multiple AUTH payloads (rather than try to combine them). Each AUTH payload would contain the signature (based on the public key from the corresponding CERT payload) of the same data which is being signed now. The idea is that if we keep the fundamental structure of IKE authentication (just having multiple payloads when necessary), it may be easier for an existing IKE implementation to be extended. _______________________________________________ IPsec mailing list -- ipsec@ietf.org<mailto:ipsec@ietf.org> To unsubscribe send an email to ipsec-le...@ietf.org<mailto:ipsec-le...@ietf.org> _______________________________________________IPsec mailing list -- ipsec@ietf.org<mailto:ipsec@ietf.org>To unsubscribe send an email to ipsec-le...@ietf.org<mailto:ipsec-le...@ietf.org>
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
