[Swan-dev] new test failures

[Andrew Cagney]

On Wed, 13 Feb 2019 at 13:44, Paul Wouters <paul at nohats.ca> 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