On Thu, 14 Apr 2016, Dang, Quynh (Fed) wrote:
1) All of the DH-groups smaller than 2K in the table 3.4 must not be used because they are not strong enough.
Right now, groups 5, 2 and 22 are being listed as "should not" which means that "must not use
unless a user has a strong reason". The problem is that a user can always have a strong reason because
there is no definition of "a strong reason".
The group 2 (1K DH group) is currently mandatory-to-implement; therefore, implementers
must implement it for interop. reason. But, the problem is that the draft is also for
users. So, there are two problems. The first one is that the working group should update
the standard to mandate a stronger DH group (or a ECC group) (which is hard to get done
soon). And, the second (which is urgent) is that the draft should explicitly say that
"users must not use those weak groups".
The draft is not for users. It is also not for default values. This is
explained at
https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-1.3
The recommendations of this document mostly target IKEv2 implementers
as implementations need to meet both high security expectations as
well as high interoperability between various vendors and with
different versions. Interoperability requires a smooth move to more
secure cipher suites. This may differ from a user point of view that
may deploy and configure IKEv2 with only the safest cipher suite. On
the other hand, comments and recommendations from this document are
also expected to be useful for such users.
Removing group 2 an 5 is expected to cause interoperability issues
because not everyone switch to group 14 for IKEv2 and not everyone
properly implements INVALID_KE and restarting with a different
DH group.
I would also not call group 5 (1536) "weak".
The fact that many existing devices are still using the group 2 ( 1K DH group)
does not make the group secure. The document should provide sound technical
guidelines for users. If a user still chooses to use a weak group, that would
be his/her own fault.
The user can only make that fault if the implementations still support
those DH groups.
2) Similarly for RSA sizes smaller than 2K and digital signatures using SHA1, "should
not" should become "must not".
And what percentage of certificate based VPN connections would break?
I suspect more than 75%
Many deployments actually kept away from 2048 bit RSA because it causes
IKE fragmentation (RFC-7383) was only added to IKEv2 in November 2014.
Give implementors 1 year, then add a year for just missing fresh 1024
bit certificates, and you are at the start of 2017. So I don't think
we can say MUST NOT for RSA 1024 bit keys.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
