Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Going through this suggestion (and tweaking it a bit): Pluses: - It is more flexible; in addition to supporting the fixed PPK's, it would also allow support for one-use PPKs (as you mention), as well as being easy to extend to handle Phillip LaFrance's PFS ideas. - Even for fixed PPK's, it

Re: [IPsec] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

I've gone through my review of the draft as well, and I think this version looks good! Thanks, Tommy > On Apr 3, 2017, at 11:25 AM, David Schinazi wrote: > > Thanks for the update! > > I've reviewed -04 and I think the draft is ready to move forward. > > Regards, >

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

On Tue, 4 Apr 2017, Tero Kivinen wrote: N(PPK_SUPPORTED) --> For example if the PPKs are taken from the 1GB one-time-pad file shared by the peers (one file per user), then the ppk_id could simply be 32-bit offset to the file, and the external PPK management module would keep track

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Tero, > > I think that if SK_pi and SK_pr are modified, then some information > > should be given to the user to help distinguish PPK errors from > > signature errors. For example, the Initiator can include something like > > > > N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 0) > > > > into the

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

[Not wearing any hats] Scott Fluhrer (sfluhrer) writes: > - Move the notifies to the prior messages (that is, in the clear). > If we do this, then by the time we derive keys, we know whether > we're using a PPK (even if the responder doesn't know which one it > is until it hears the initiator's

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Valery Smyslov writes: > > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the > > IKEv2 authentication will fail, and we will get exactly same failure > > for wrong PPK than we do with wrong shared key or digital signature > > failures. This means that attacker do not gain any

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Scott, > I started editting the draft to incorporate this change, and I ran into a > conflict with another part of the > protocol: incremental rollout. I'd like some quick advice about how to deal > with the conflict. > > Here's the feature it's in conflict with: in order to support