On Tue, Oct 18, 2016 at 3:33 AM, Tero Kivinen <kivi...@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
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
>> 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.
> saag mailing list
"Man is born free, but everywhere he is in chains".
IPsec mailing list