Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Mar 2015 08:01:19 -0800

On Feb 26, 2015, at 2:11 PM, Paul Hoffman <[email-masked]> wrote:
> Greetings again. A few people have expressed interest in having https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG item for IPsecME. If you want this as a WG document, and you are willing to review drafts as they move through, please say so on this thread. If you are opposed to this being a WG document, please say so (and say why). Thanks in advance.

This got very little interest, which surprised me. Without a few more people who will commit to review the document and offer comments, we can't really call it a WG work item. Is there really so little interest in new algorithms that are being adopted in other protocols?

If you are an IPsec implementer, it would be very useful to know whether or not you would support adding this algorithm to your implementation, and why.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Mar 2015 13:46:41 -0500 (EST)

> If you are an IPsec implementer, it would be very useful to know whether or not you would support adding this algorithm to your implementation, and why.

libreswan will add support for this algorithm in IKE and use the kernel
implementation for ESP.

Even with low "interest", this should be taken on by the WG, or else we
will just get another private use number like SERPENT(252) or
TWOFISH(253) or KAME_NULL(251) that everyone will use.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Fri, 6 Mar 2015 20:53:16 +0200

> On Mar 6, 2015, at 6:01 PM, Paul Hoffman <[email-masked]> wrote:
> 

Obviously I’m in favor of adoption, as I’m the author.

[vendor hat on]
If (when?) this becomes an RFC, Check Point will implement this, in all likelihood this year or early next year.

I of course can’t promise dates or versions when this is delivered as a feature in our product - that is more of a UI decision, and out of my hands.

Yoav

---

From: Jim Knowles <[email-masked]>
Date: Fri, 6 Mar 2015 12:57:48 -0800

I've read the draft and favor adoption as a working group item.  Although I can't speak for my company, I would push for, and expect, support to be added to a future product release once reviewed and advanced.

Jim Knowles

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Friday, March 06, 2015 8:01 AM
To: IPsecME WG
Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305

--Paul Hoffman
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 7 Mar 2015 09:07:20 +0300

> > Greetings again. A few people have expressed interest in having 
> > https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG 
> > item for IPsecME. If you want this as a WG document, and you are willing 
> > to review > drafts as they move through, please say so on this thread. 
> > If you are opposed to this being a WG document, please say so (and say 
> > why). Thanks in advance.
>
> This got very little interest, which surprised me. Without a few more 
> people
> who will commit to review the document and offer comments, we can't really
> call it a WG work item. Is there really so little interest in new 
> algorithms that
> are being adopted in other protocols?
>
> If you are an IPsec implementer, it would be very useful to know whether 
> or not you
> would support adding this algorithm to your implementation, and why.

We (ELVIS-PLUS) will add this algorithm into our products
if it is widely deployed (with some definition of "widely").
And since the algorithm is popular it seems to be the case.

Anyway I'm in favour of adopting the document so that
we don't have interoperability problems in the future.

Valery.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Mar 2015 17:20:24 +0200

> If you are an IPsec implementer, it would be very useful to know whether or not you would support adding this algorithm to your implementation, and why.

Counting both threads, we’ve seen support from MCR, Tero, Paul W, Valery, and Jim Knowles. Together with me this represents at least 5 independent implementations.

I think this should be enough for algorithms that some are suggesting should be the MTI for TLS 1.3 ([1]), and where the algorithms themselves can be considered “vetted”. I know TLS is a different protocol, but there’s no real difference in the way IPsec and TLS use symmetric crypto.

Yoav

[1] http://www.ietf.org/mail-archive/web/tls/current/msg15452.html