Re: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-03.txt

2018-05-09 Thread David Schinazi 
Thanks for the update, authors! I've reviewed -03 and it looks great to me.

David


> On May 9, 2018, at 13:09, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions WG of 
> the IETF.
> 
>Title   : Implicit IV for Counter-based Ciphers in 
> Encapsulating Security Payload (ESP)
>Authors : Daniel Migault
>  Tobias Guggemos
>  Yoav Nir
>   Filename: draft-ietf-ipsecme-implicit-iv-03.txt
>   Pages   : 8
>   Date: 2018-05-09
> 
> Abstract:
>   Encapsulating Security Payload (ESP) sends an initialization vector
>   (IV) or nonce in each packet.  The size of IV depends on the applied
>   transform, being usually 8 or 16 octets for the transforms defined by
>   the time this document is written.  Some algorithms such as AES-GCM,
>   AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do
>   not require an unpredictable nonce.  When using such algorithms the
>   packet counter value can be used to generate a nonce.  This avoids
>   sending the nonce itself, and saves in the case of AES-GCM, AES-CCM,
>   AES-CTR and ChaCha20-Poly1305 8 octets per packet.  This document
>   describes how to do this.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-03
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02

2018-05-09 Thread Daniel Migault 
Hi,

Thank you Tero for the review. Please find in line my responses in line.
version 02 of the draft has been updated accordingly to your review.

Yours,
Daniel

On Fri, Apr 6, 2018 at 4:08 PM, Tero Kivinen  wrote:

> While doing my IANA review on the document I found some small nits
> about it. Here are my comments to the document:
>
> --
>
> Typo in abstract:
>
> This avoids
>sending the nonce itself, and savec in the case of AES-GCM, AES-CCM,
>  ^
>
> I assume it should be "saves".


This has been changed to 'saves'.


> --
>
> In section 2 missing closing parenthesis and period:
>
> ... The same applies for
>ChaCha20-Poly1305 ([RFC7634].  Currently this nonce is sent in each
>^
>
> add missing ")".
>
> The missing ")" has been added

> --
>
> In section 4, I think SA is better word than SPI to describe the IPsec
> security association. SPI is just the number identifying the SA, SA is
> the actual security association which includes sequence number, key,
> direction, algorithms etc.
>
> So change:
>
>As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are
>used, Implicit IV as described in this document MUST NOT be used in
>setups with the chance that the Sequence Number overlaps for one SPI.
>Multicast as described in [RFC5374], [RFC6407] and
>[I-D.yeung-g-ikev2] is a prominent example, where many senders share
>one secret and thus one SPI.
>
> with
>
>As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
>used, Implicit IV as described in this document MUST NOT be used in
>setups with the chance that the Sequence Number overlaps for one
>SA. Multicast as described in [RFC5374], [RFC6407] and
>[I-D.yeung-g-ikev2] is a prominent example, where many senders
>share one secret and thus one SA.
>
> The three occurrences of SPI have been changed to SA.


> --
>
> This text is bit misleading
>
>A similar mechanism could be used by associating the most
>significant byte of the Sequence Number to a sender, while the 3
>remaining bytes will be used to carry the counter value. Such
>mechanism prevents the use of Extended Sequence Number and limits
>the number of packet to be sent to 2** 24 = 16777216, that is 16 M.
>
> To solve the issue you could of course move the sender byte as the
> least significant byte in the sequence number, i.e., in that case the
> system could use extended sequence numbers, and the limit of the
> packet would not be that bad. Of course this still has the issue that
> normal replay window processing does not work with cases where
> sequence numbers are not used in numeric order (this same issue is in
> the normal RFC6407 cases).
>
> On the other hand, I think it might be better to just forbid the
> implicit IV on multicast cases, and we do not need to explain all the
> issues there.
>
>
I propose to add your comment and mention that Implicit IV is not
recommended with multicast so the reader interested in multicast
understands the motivation for not using it.


As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
   used, Implicit IV as described in this document MUST NOT be used in
   setups with the chance that the Sequence Number overlaps for one SA.
   Multicast as described in [RFC5374], [RFC6407] and
   [I-D.yeung-g-ikev2] is a prominent example, where many senders share
   one secret and thus one SA.  Section 3.5 of [RFC6407] provides a
   mechanism that MAY be used to prevent IV collisions when the same key
   is used by multiple users.  The mechanism consists in partitioning
   the IV space between users by assigning the most significant byte to
   a user.  When implicit IV transforms are used, such mechanism cannot
   be applied as the IV is not sent, but instead it is derived from the
   Sequence Number.  A similar mechanism could be used by associating
   the most significant byte of the Sequence Number to a sender, while
   the 3 remaining bytes will be used to carry the counter value.  Such
   mechanism prevents the use of Extended Sequence Number and limits the
   number of packet to be sent to 2** 24 = 16777216, that is 16 M.  Note
   that associating instead the least significant byte of the Sequence
   Number to the sender, would enable the system to use Extended
   Sequence Number and as such extend the limit of packet to be sent to
   2 ** ( 24 + 32 ) = 72057594037927936, that is 72 P.  Note also that
   in both cases the Sequence Number are not interpreted as numeric
   values which impacts the replay window processing defined in
   [RFC4302] and [RFC4302].

   Unless some mechanism are provided to avoid collision between
   Sequence Number, ( and so IV ), Implicit IV MUST NOT be used.  As
   such, it is NOT RECOMMENDED to use Implicit IV with Multicast.

another alternative could be:


As the IV

[IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-03.txt

2018-05-09 Thread internet-drafts 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of 
the IETF.

Title   : Implicit IV for Counter-based Ciphers in 
Encapsulating Security Payload (ESP)
Authors : Daniel Migault
  Tobias Guggemos
  Yoav Nir
Filename: draft-ietf-ipsecme-implicit-iv-03.txt
Pages   : 8
Date: 2018-05-09

Abstract:
   Encapsulating Security Payload (ESP) sends an initialization vector
   (IV) or nonce in each packet.  The size of IV depends on the applied
   transform, being usually 8 or 16 octets for the transforms defined by
   the time this document is written.  Some algorithms such as AES-GCM,
   AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do
   not require an unpredictable nonce.  When using such algorithms the
   packet counter value can be used to generate a nonce.  This avoids
   sending the nonce itself, and saves in the case of AES-GCM, AES-CCM,
   AES-CTR and ChaCha20-Poly1305 8 octets per packet.  This document
   describes how to do this.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-03
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec