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> 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> > <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> > <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> 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 >> To unsubscribe send an email to ipsec-le...@ietf.org >> > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org > > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org > >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
