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

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

Thank you again for the comments!
Yours,
Daniel

On Fri, Oct 18, 2019 at 3:43 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote:
> >    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
> >    <noreply@ietf.org> wrote:
> >
> >      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*.
> >
> >    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.
>
> Thanks!
>
> >
> >      Section 2
> >
> >      nit: s/Initialize/Initialization/
> >
> >    Fixed
> >
> >      nit: s/similar mechanism/similar mechanisms/ plural
> >
> >    Fixed
> >
> >
> >      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
> >
> >    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 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.
> >
> >    """
>
> Ah, it seems I was reading too quickly and missed the precondition.
> Thanks for the attention to detail!
>
> -Ben
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>