On Wed, 13 Feb 2019 at 13:44, Paul Wouters <[email protected]> wrote: > > On Wed, 13 Feb 2019, Andrew Cagney wrote: > > > It would be from more algorithms being added to defaults. But there's > > another change I think needs to follow. Namely changing the way IKE > > proposals are formatted. Namely remove the smart that suppresses > > <integ>, so that what was: > > > > <encrypt>-<prf>-<dh> > > AES_CBC-HMAC_SHA1-DH31 > > AES_GCM_16-HMAC_SHA1-DH31 > > That is really encrypt-integ-dh right? > We don't specify/print the prf until now because we assume integ == prf > except for AEAD.
Above is or IKE the code was printing the PRF because that was slightly shorter than the equivalent INTEG. ESP: <encr>-<integ> AH: <integ> (so yea, I see your point, IKE isn't exactly consistent) > > > becomes the longer: > > > > <encrypts>-<prfs>-<integs>-<dhs> > > AES_CBC-HMAC_SHA1-HMAC_SHA1_96-DH31 > > AES_GCM_16-HMAC_SHA1-NONE-DH31 > > > > thoughts? > > I'd prefer encr-integ-prf-dh maybe ? I don't know. What ever it is, I think it needs to be possible for the output format to be cut/pasted into a config file and just work. With the old proposals and format it was possible. So looking at the parser, officially, for IKE, it expected: encr-prf-dh but, unofficially, it could also parse (I don't think this was documented?): encr-prf-integ-dh if we reverse things vis: encr-integ-[prf]-dh then proposals like: aes-sha1 all still work fine - prf can be painfully derived from integ, but: aes_gcm-sha1 would break; force aes_gcm-none-sha1, or require some heuristic to figure out <integ> should be skipped. > > I'll look at this. It wasn't expected. IKE proposals should prefer > > 256 while ESP proposals should prefer 128. > > Ok, > > Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
