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.
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
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.
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
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.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
