[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [IPsec] Fw:  WG Last Call on draft-ietf-ipsecme-rfc4307bis
From:       "Dang, Quynh (Fed)" <quynh.dang () nist ! gov>
Date:       2016-04-14 17:21:53
Message-ID: BN1PR09MB124FF51AE06C547926E0E15F3970 () BN1PR09MB124 ! namprd09 ! prod ! outlook ! com
[Download RAW message or body]

Paul,

I just copied from your quote in section 1.3 here: "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."

We should be clear about recommendation for interoperability reason and \
recommendation for security reason: they are different.

Quynh. 
________________________________________
From: IPsec <ipsec-bounces@ietf.org> on behalf of paul@nohats.ca <paul@nohats.ca>
Sent: Thursday, April 14, 2016 11:22 AM
To: Dang, Quynh (Fed)
Cc: IPsecME WG; Paul Hoffman; Frankel, Sheila E. (Fed)
Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]