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

On Tue, Oct 18, 2016 at 3:33 AM, Tero Kivinen <kivinen@iki.fi> wrote:
> 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.

In sane protocols the default MTI ciphersuite is always ready to be
used for exactly this reason. IKE's extensively flexible configuration
knobset was not a good idea for this reason.

>
> 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.

This seems reasonable to me.

>
> 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.

That's sort of the point. We want these implementations to NOT support
these groups, just as RC4 die-die-die meant TLS implementations no
longer support RC4.

> --
> kivinen@iki.fi
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.