I agree with Daniel that type-1 and type-2 are not in confliction that we could only choose one. Both choices have pros and cons. Either one has their assumptions of the suitable scenarios.
I also in favor of type-2. Because I think the hybridization is temporary and pure PQ is the future, and IMHO type-2 would be better. But none of us can guarantee our assumptions will be the fact in the future. PQ migration is not an easy thing, it will take time and we need more practices during the migration. So I think it’s better to not preclude anyone and provide the solutions for each one. The implementers will choose accordingly based on their demand. And finally, the experience and practices during PQ migration will be learned, and we will see which one (or both two) will be left. Regards & Thanks！ Wei PAN (潘伟) From: tirumal reddy <kond...@gmail.com> Sent: Wednesday, November 6, 2024 9:11 AM To: Daniel Van Geest <daniel.vange...@cryptonext-security.com> Cc: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; Scott Fluhrer <sfluhrer=40cisco....@dmarc.ietf.org>; ipsec@ietf.org Subject: [IPsec] Re: [EXT] Re: draft-hu-ipsecme-pqt-hybrid-auth Type-2 cannot be used with other protocols like TLS without protocol changes, assuming a network function uses both TLS and IPSec protocols, it will have to support both Type-1 and Type-2. Hence, the preference for Type-1. On Tue, 5 Nov 2024 at 22:51, Daniel Van Geest <daniel.vange...@cryptonext-security.com<mailto:daniel.vange...@cryptonext-security.com>> wrote: I don't think Type-1 precludes Type-2 or vice-versa and there are use cases for either. In both cases, assuming that hybridization is not permanent and not a flag-day, during the transition period two certificate chains will need to be managed, always a traditional one and either a composite one (Type-1) or a pure PQ one (Type-2). With Type-2, once the transition is complete you already have deployed pure PQ roots and chains and don't have to do anything but turn off hybrid and enforce PQ. With Type-1, you have to deploy pure PQ roots and chains after the hybrid transition (or have deployed them during the transition in which case you had to deal with 3 chains). So, if hybridization is going to be permanent then I think that Type-1. If hybridization is going to be a step towards pure PQ authentication then I think Type-2 is probably better, but would want to see some security analysis of draft-hu-ipsecme-pqt-hybrid-auth Type-2, draft-guthrie-ipsecme-ikev2-hybrid-auth and/or RFC 4379. But then, if hybridization is temporary then maybe we don't need to do all this protocol work and just go with Type-1 as the easy way out. This probably depends on your opinion of how often new algorithm transitions will occur and whether hybridization will be needed at each transition. A question, is the opposition to RFC 4379 only about the additional round trip, or are there security concerns? Perhaps the negotiation of draft-guthrie-ipsecme-ikev2-hybrid-auth could be applied to RFC 4379 instead to ensure that hybridization is guaranteed. RFC 4379 has the advantage of being able to verify different entities (e.g. the user and the machine) as well as, it seems to me, providing hybridization for a single entity. Of course, RFC 4379 could be used in combination with composite signatures or maybe draft-hu-ipsecme-pqt-hybrid-auth-Type-2/draft-guthrie-ipsecme-ikev2-hybrid-auth to get both hybridization and multiple-entity authentication. If both types are specified, I don't think they should be done in the same draft, Type-1 can be more or less a copy-paste of draft-reddy-ipsecme-ikev2-pqc-auth with different OIDs and can progress quickly while Type-2 needs more thought and implementations would probably be slower to roll it out. Daniel With Type-2, whether it be draft-hu-ipsecme-pqt-hybrid-auth On 2024-11-05 3:42 p.m., Blumenthal, Uri - 0553 - MITLL wrote: I prefer Type-2, as it seems a more straightforward approach overall, with fewer chances of “cross-interruptions”. — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory On Nov 5, 2024, at 09:28, tirumal reddy <kond...@gmail.com><mailto:kond...@gmail.com> wrote: 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. com@ dmarc. ietf. org><mailto:sfluhrer=40cisco.%E2%80%8Acom@%E2%80%8Admarc.%E2%80%8Aietf.%E2%80%8Aorg> wrote: ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory. ZjQcmQRYFpfptBannerEnd 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<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
