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 > 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. > -- > kivi...@iki.fi > > _______________________________________________ > saag mailing list > s...@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
