To clarify one thing, there are three separators involved: '-' separates algorithms within a proposal ';' within a proposal, separates DH from the rest (kind of legacy) ',' separates proposals
On Sun, 19 Aug 2018 at 14:57, Paul Wouters <[email protected]> wrote: > > On Sun, 19 Aug 2018, Andrew Cagney wrote: > > > ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24, ... > > not sure I like this, because it doesn't handle mixed use of > AEAD/non-AEAD? Although we hope that non-AEAD is going extinct soon. The RFC says you can't mix AEAD and non-AEAD crypto. So two proposals would be needed; separated by a comma (like we do now): ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24,aes_gcm,chacha20_poly1305-sha1-dh21 so the two proposals contain: encrypt=aes_ctr,aes_cbc,3des_cbc integ=hmac_sha1_96,hmac_sha2_256_126 prf=hmac_sha1,hmac_sha2_256 dh=dh24 encrypt=aes_gcm,chacha20poly1305 [integ=none] prf=hmac_sha1,hmac_sha2_256 dh=dh24 > > Currently it isn't possible to descripe a single proposal with > > multiple algorithms. This both limits what we can send across the > > wire (and annoying to me, means we can't feed the default proposals > > into the parser). One possible syntax is: > > > > ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24,... > > or: > > ike-encr=aes,aes_gcm > ike-integ=sha2,sha1 > ike-dh=dh22,dh23 > esp-encr=aes_gcm,aes > esp-integ=sha2 > > The issue is again AEAD/non-AEAD, where we turn integ into prf Part of the magic INTEG rule is to not convert the PRF into INTEG when AEAD. > also, we should be able to ignore dhXX when pfs=no. We already had our > first issue where someone adding pfs=no got their ike= line rejected. > I think I would prefer a silent ignore. I would really like to see the > future to mandate PFS. Since you cannot really know if your IPsec SA > will be established from the Initial Exchanges or the Create_Child_sa, > there is no sane configuration where this would/should have different > values. Do you mean IKE or ESP? PFS=NO does cause an ESP line containing explicit DH to be rejected: algparse -ikev2 'esp=aes_gcm;modp2048' ERROR: ESP DH algorithm MODP2048 is invalid as PFS policy is disabled it was somewhat silent and contradictory (between IKEv1 and IKEv2) but we deliberately stopped that. I agree that having DH23 esp=aes-sha1-dh23 ignored during AUTH and then used later is confusing. > Another way would be to allow people to specify actual proposals on the > wire: > > ike=aes_gcm-sha2,chacha20poly1305,dh21;aes256,3des,sha2,sha1,dh21 I'm not sure what this is trying to describe. For instance, everything in a single proposal, or lots of proposals with defaults filled in. > Which would get simpler when non-AEAD usage dies of. > > The got-ya is with 'none'. For instance, in both: > > > > esp=aes-none > > ike=aes_gcm-none > > > > while 'none' could mean either DH or INTEG (yes, the latest RFC added > > 'none' for DH), the above strategy interprets it as integrity. The > > likely workaround is to specify: > > > > ike=aes_gcm;none > > > > to force none as DH. > > everything "none" should be autodetected by us and never need > specification by the enduser. It is simply too confusing to tell > them use "none" for integrity. Except when we need to describe an ESP/AH proposal suite containing: 1. AES_GCM-DH23 2. AES_GCM-DH=NONE which would be: AES_GCM-DH23,AES_GCM;NONE _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
