Subject: [IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 16 Oct 2019 20:30:06 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ipsecme-implicit-iv-08: No Objection

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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

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

Thanks for addressing my Discuss!

A few new comments on the -08:

Abstract

If we're going to differentiate between nonce and IV, I think that
the algorithms require a unique but not necessarily unpredictable *nonce*,
rather than *IV*.

Section 2

nit: s/Initialize/Initialization/

nit: s/similar mechanism/similar mechanisms/ plural

Section 7

My previous ballot was trying to note that the sender/receiver counters
MUST be reset (as noted here) even without this document, as part of
the core ESP requirements.  So we don't need to use the "MUST" here as
if it's a new requirement; we can just say that this behavior is already
present due to the preexisting requirements

---

From: Daniel Migault <[email-masked]>
Date: Thu, 17 Oct 2019 22:37:10 -0400

Hi Benjamin,

Thanks you for the comments. Please see in line my responses.

Yours,
Daniel
On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> I would preferred to have IV instead of nonce is that IPsec provides
constraints on the IV, not the nonce. I expected to have switched from
algorithms to their implementations by writing "when used with IPsec" in
the previous sentence. In order to flip-flop from algorithm to their
implementations with IPsec, I propose to clarify this as follows:

OLD:
These
algorithms require a unique IV but do not require an unpredictable IV.

NEW:
This IV must be unique but can be predictable.

> nit: s/Initialize/Initialization/
Fixed

> nit: s/similar mechanism/similar mechanisms/ plural
Fixed

> Well, the reason I included it was that - at least my reading of ESP - ESP
seems to require key to be rekeyed when the SN reaches its limit only when
anti-replay is activated. In our case, we need to have this property even
without anti replay protection. Here is the text I considered rfc4303
section 2.2

"""

The sender's counter and the receiver's counter are initialized to 0
   when an SA is established.  (The first packet sent using a given SA
   will have a sequence number of 1; see Section 3.3.3
<https://tools.ietf.org/html/rfc4303#section-3.3.3> for more details
   on how the sequence number is generated.)  If anti-replay is enabled
   (the default), the transmitted sequence number must never be allowed
   to cycle.  Thus, the sender's counter and the receiver's counter MUST
   be reset (by establishing a new SA and thus a new key) prior to the
   transmission of the 2^32nd packet on an SA.

"""

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Oct 2019 12:43:29 -0700

On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote:
>    On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker
>    <[email-masked]> wrote:
> 
>      Please refer to
>      https://www.ietf.org/iesg/statement/discuss-criteria.html

Thanks!

>     will have a sequence number of 1; see Section 3.3.3 for more details

Ah, it seems I was reading too quickly and missed the precondition.
Thanks for the attention to detail!

-Ben

---

From: Daniel Migault <[email-masked]>
Date: Fri, 18 Oct 2019 21:41:05 -0400

Thank you for the response, I just published a new version with the
mentioned  text.

Thank you again for the comments!
Yours,
Daniel