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
