Subject: [IPsec] RFC4307bis working version 3

From: Daniel Migault <[email-masked]>
Date: Wed, 20 Jan 2016 15:04:40 -0600

Hi,

Please find the working version of version 03:
https://github.com/mglt/drafts/commit/40e6a1e0e99064b54a328e27f0c3d498c2c7164c
Feel free to provide comments.

BR,
Daniel

A) adding recommendations for DH - Group 22- 24:
<c>22</c><c>1024-bit MODP Group with 160-bit Prime Order
Subgroup</c><c>MUST NOT</c>
<c>23</c><c>1024-bit MODP Group with 224-bit Prime Order
Subgroup</c><c>MUST NOT</c>
<c>24</c><c>1024-bit MODP Group with 256-bit Prime Order
Subgroup</c><c>MUST NOT</c>

with the following comment:
Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP Group
with 224-256-bit Prime Order Subgroup are exposed to synchronization
or transcription attacks.

B) PKIX
Do we need something more ?

C) Intended Audience:
Specifying the implementer vs users:

The recommendations of this document mostly target IKEv2 implementers
as implementations needs to meet both high security expectations as
well as high interoperability between various vendors and with
different updates. 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 suites.
On the other hand, comments and recommendations are also expected to
be useful for such users.

D) Other Hash function has been removed

E) Removing Curve25519 as not yet defined

F) ENCR payload replaced by Encrypted Payload. It seems an INTG
payload is running somewhere, but I could not find it.

G) removing recommendation for non defined crypt suites:
Ed25519 (MAY),  Ed25519ph(MAY), Ed448(MAY), Ed448ph(MAY).
I would like to be able to provide the right OID ASN1 code for the
recommended authentication methods.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Jan 2016 00:25:57 -0500 (EST)

> Feel free to provide comments.

+      <t>The recommendations of this document mostly target IKEv2 implementers as implementations needs to meet

Remove "mostly"?

implementations needs to meet both high security expectations as well as high interoperability between various vendors

"high interoperability" does not really work for me. How about "wide
interoperability" or industry-wide or "a wide range of
interoperability".

a user -> an user

Avoid the word "cipher suites" because it kind of has a TLS meaning. How
about safest algorithms ?

On the other hand, -> Although

+        <t>Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP Group with 224-256-bit Prime Order 
+        Subgroup are exposed to synchronization or transcription attacks.</t>

I'd split this up. 1024-bit MODP Group is getting too weak to be
expected to provide a

Here are the recommendations -> Recommendations

lower than 2048 -> smaller than 2048

> Do we need something more ?

Maybe try and limit it and see the PKIX authenticatiom should use an
algorithm of equal of stronger security than the PRF/INTEG ?

> Specifying the implementer vs users:

See above.

Perhaps after this bump the draft and ask the WG for feedback?

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jan 2016 10:16:41 +0200

> On 21 Jan 2016, at 7:25 AM, Paul Wouters <[email-masked]> wrote:
> 
> 

Nope: http://gmatclub.com/forum/a-user-or-an-user-111564.html