As someone who implemented both RFC8784 and the new alternative approach, I want to say I agree with Valery in the point below:
1. The code logic is simpler, and easier to follow and verify, with having this separate notification type (the PPK code logic is already quite complicated). 2. My intuition also tells me having a separate notification type is a more natural approach. The two notification types do represent two different semantic purposes. While we are at it, I am interested in whether there are any other implementations that already implemented the draft? (beside Valery's/ELVIS-PLUS and libreswan) Maybe those people can chip in with their opinion. Regards, Vukašin пет, 26. јул 2024. у 16:04 <ipsec-requ...@ietf.org> је написао/ла: > Date: Fri, 26 Jul 2024 16:59:54 +0300 > From: "Valery Smyslov" <smyslov.i...@gmail.com> > Subject: [IPsec] Re: Review of draft-ietf-ipsecme-ikev2-qr-alt > To: "'Tero Kivinen'" <kivi...@iki.fi> > Cc: ipsec@ietf.org > Message-ID: <015501dadf64$17ce7160$476b5420$@gmail.com> > Content-Type: text/plain; charset="us-ascii" > > *snipped* > > > > In this case additional checks should be performed to make sure that > > > only PPK_ID formats with confirmation are used for this extension. > > > It's easier to check this based on the Notify Type, than on PPK_ID > > > format. The latter is usually performed much deeper in code, when you > > > parse the ID. In other words, having its own Notify type allows to > > > make sanity checks easier. > > > > I do not think that makes that big difference. We currently have 2 PPK ID > formats > > defined, and I would assume most implementations uses only one of them... > > I disagree, it does. I prefer notification format to depend on notify type > than on > notification content. > > > On the other hand I think having PPK ID format that includes confirmation > would > > benefit the old PPK method too. And when you are calling the function to > verify that > > PPK ID passes confirmation it would always fail for those formats which > do > not > > have confirmaton, thus that would automatically check that only ones that > have > > confirmation are accepted. > > It is not that simple. Actually, your proposal complicates code and adds > potential vulnerabilities. > Note, that the current draft uses both PPK_IDENTITY_KEY (with confirmation) > in request > and PPK_IDENTITY (w/o confirmation, the same as in RFC 8784) in response. > All PPK_ID types (currently defined and future) are eligible to appear in > both notifications. > The reason two notification are used is that only responder checks > the confirmation. The initiator proposes PPK and provides the confirmation, > the responder checks whether it is correct. There is no need for initiator > to check it again, thus the confirmation is omitted in response. > > If it were included in the response then we'd have a bunch of problems: > the initiator have either check it again (for what?) or ignore. > In the former case we have to handle situations when the confirmation > is incorrect (that actually is difficult to be handled gracefully, > since this is probably a broken responder implementation in which case > the initiator should not even inform the responder about the problem, > making > it difficult > to debug if that happens). In the latter case we have a perfect covert > channel > (data that is transmitted, but never used in the protocol), which I want to > avoid. > For these reason the response doesn't include confirmation and > uses different notification type. >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
