Subject: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 30 Aug 2016 06:38:48 -0700

Stephen Farrell has entered the following ballot position for
charter-ietf-ipsecme-10-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ipsecme/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There are some typos (s/MIT/MTI) and bits of English that
need to be tidied up.

I have a suggestion about this bit of work:

"IKEv1 using shared secret authentication was partially resistance to
quantum computers. IKEv2 removed this feature to make the protocol
more usable. The working group will add a mode to IKEv2 or otherwise
modify IKEv2 to have similar quantum resistant properties than IKEv1
had."

My suggestion is twofold:

1) - s/will add/will consider adding/

and to add to the end:

2) "In doing this work the WG will consider ongoing work on
quantum-resistance 
in the CFRG, and whether it is better to re-instate the same level of
resistance
that was present in IKEv1 or to wait for more recent work (e.g. in CFRG)
to 
mature."

The reason I suggest this is that it's possible the WG might conclude
that
it's better to wait for some newer QR stuff from CFRG. The current
wording
seems to commit the WG to firing ahead anyway, and we might overall be
better if there are fewer QR mechanisms proposed, rather than adding
some
now when it might be better to wait a while longer.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Aug 2016 18:09:36 +0300

Hi, Stephen

> On 30 Aug 2016, at 4:38 PM, Stephen Farrell <[email-masked]> wrote:

> now when it might be better to wait a while longer.

There is a reason for this language. Obviously what this item suggests is not the solution to the QC-equipped adversary that we are looking for. But the good solution is not likely to surface any time soon. 

In the meantime we are hearing that some deployments are reverting to IKEv1 because of its perceived better quantum resistance. IKEv1 has been deprecated for over ten years. In addition to some objective shortfalls, IKEv1 has been considered a legacy feature for many implementers. For an anecdote, we never bothered to implement IPv6 support in IKEv1. The prospect of a user demanding not to have to choose between IPv6 and quantum resistance is not something I look forward to.

This is the motivation behind this item. If we were looking for the good solution this item should probably have been phrased as “the WG will follow research into quantum resistant algorithms for authentication and key exchange and consider their suitability to IKE”, because I don’t think we’re going to have something concrete in the next 3-5 years. Fixing this to make it no worse than IKEv1 (not aiming very high, I guess) is doable in months.

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Aug 2016 14:55:42 -0400

> https://datatracker.ietf.org/doc/charter-ietf-ipsecme/

I went ahead and changed the one instance of MIT to MTI, thanks for
catching that.  I also read through through the English as well again
and suggest changing the second to last paragraph to the following:

Currently, widely used counter mode based ciphers send both the ESP
sequence number and IV in form of counter, as they are very
commonly the same.  There has been interest to work on a document that will
compress the packet and derive IV from the sequence number instead of
sending it in separate field. The working group will specify how this
compression can be negotiated in the IKEv2, and specify how the
encryption algorithm and ESP format is used in this case.

> now when it might be better to wait a while longer.

I'll leave this text alone from the WG response, at least for now.
Being able to work on it in months makes sense even if it isn't the
best long term solution.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Aug 2016 20:06:34 +0100

> Being able to work on it in months makes sense even if it isn't the

I'm ok with that. But note that my suggested wording is not meant
to commit the WG to waiting on CFRG, only to leave that call for
later.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Aug 2016 15:10:36 -0400

> to commit the WG to waiting on CFRG, only to leave that call for

If others from the WG want to chime in, please do.  I'll help with the
text updates as agreed.

Thanks!

-- 

Best regards,
Kathleen