On Tue, 22 Sep 2020 at 23:09, Paul Wouters <[email protected]> wrote: > On Tue, 22 Sep 2020, Andrew Cagney wrote: > > > On Tue, 22 Sep 2020 at 21:36, Paul Wouters <[email protected]> wrote: > > On Tue, 22 Sep 2020, Andrew Cagney wrote: > > > > > Now that the parser can accept <aead>-NONE- <prf>-<dh>, should > "NONE" be included when logging those proposals? For > > instance: > > > > > > OLD: > > > algparse -v2 'ike=aes_gcm-sha1-dh21' > > > AES_GCM_16-HMAC_SHA1-DH21 > > > algparse -v2 'ike=aes_gcm_16-none-hmac_sha1-dh21' > > > AES_GCM_16-HMAC_SHA1-DH21 > > > > > > NEW: > > > algparse -v2 'ike=aes_gcm-sha1-dh21' > > > AES_GCM_16-NONE-HMAC_SHA1-DH21 > > > algparse -v2 'ike=aes_gcm_16-none-hmac_sha1-dh21' > > > AES_GCM_16-NONE-HMAC_SHA1-DH21 > > > > > > the main reason is to avoid any confusion over how integrity is > being computed. > > > > I think that would be good, yes. > > > > > As a follow-up, what about non-AEAD algorithms; which get really > unwieldy. > > > > I'm not sure what you mean? > > > > > > algparse -v2 'ike=aes-sha2-dh31' > > AES_CBC-HMAC_SHA2_256-DH31 > > > vs the canonical: > > > > algparse -v2 'ike=aes-sha2-dh31' > > AES_CBC-HMAC_SHA2_256_128-HMAC_SHA2_256-DH31 > > Oh I see. do we repeat the PRF after INTEG because these are always the > same in the non-AEAD case.
When INTEGs and PRFs are a direct map only the slightly shorter PRFs are printed (if they are somehow different; say from impairing) then both are shown. The two choices I point forward were: <encr>-<prf>-<dh> AES_CBC-HMAC_SHA2_256-DH31 <encr>-<integ>-<prf>-<dh> AES_CBC-HMAC_SHA2_256_128-HMAC_SHA2_256-DH31 I guess technically there's also: <encr>-<integ>-<dh> AES_CBC-HMAC_SHA2_256_128-DH31 I think I'm fine not doing it, since we don't > support prf != integ unless AEAD. It would be more consistent to do it. > I have no strong opinion on what's better. > > If we don't want to support prf!=integ then, I suspect, not showing the quad, even when the PRF/INTEG direct map, is safer. So add -none- and then let the dust settle.
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
