Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)

[Tero Kivinen <[e-mail]>]

Yoav Nir writes:
> I’m not entirely comfortable with calling something a MUST NOT when all we
> have is conjecture, but I have no love and no need of those DH groups.

Same here, and it also makes it so that we cannot say our
implementation is conforming rfc4307bis, even when we do already have
support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to
implement algorithms in the new document, but we do also have code to
propose the RFC5114 MODP groups, if user configures them to be used.

Changing that is of course is very easy to do in implementation, but
before this is deployed etc will take some time, and there is change,
that some customer has explictly configure RFC5114 2048-bit MODP group
in use, and by removing that we suddenly break their existing
configuration.

It is always annoying to explain to customer why we explictly broke
their existing configurations unless there is real security reason for
it. Looking that the paper, this only applies to the 1024-bit MODP
group in RFC5114, even the paper says that 2048-bit MODP groups are
safe, even if they would have same backdoor.

We are already downgrading normal 1024-bit MODP group to SHOULD NOT,
and this would make it two reasons to make RFC5114 1024-bit MODP group
to SHOULD NOT (too short, and might be backdoored), so perhaps the
compromize can be to make RFC5114 1024-bit MODP group number 22 to
MUST NOT, and keep the groups 23-24 as SHOULD NOTs.

Anyways we need to modify the rfc4307bis text and add reference to
this paper, as one more reason why groups 22-24 MUST NOT/SHOULD NOT be
used.

> I don’t believe anyone else depends on these groups (at least in
> IPsec), so I’m fine with such a change.

I do not think people depend on them, but I assume there is quite a
lot of implementations there that can be configured to use them if
explictly asked, thus making them MUST NOT will make it so that those
implementations will not be conforming rfc4307bis.
-- 
[e-mail]