Subject: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 2 Apr 2019 17:39:22 +0300

Hi,

It's a bit late, since WGLC for the draft is already over, but hope it's not too late.

While re-reading of the draft I realized, that it's completely silent on the necessity 
of Key Length attribute in newly defined transforms. AES accepts keys
of different sizes, so there must be a way to negotiate key length 
(by including key length attribute). Currently the draft completely ignores
this issue, that may lead to interoperability problems. 

I suggest either to copy-paste relevant text from any other AES-transform related 
RFC (e.g. 4106 or 5282), or make it a bit smarter: make a key length attribute optional
and define a default key length for the case when it is absent (e.g. 256 bits).
It'll allow us to save few bytes by omitting attribute for most common cases.

Either way, something should be added to the draft to remove current ambiguity
(this issue seems to not be concerned with Chacha20, which is defined with 256 bit key only).

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Apr 2019 12:51:41 -0400 (EDT)

> and define a default key length for the case when it is absent (e.g. 256 bits).

Do not do this. There are broken implementations and interop issues on
this already by broken clients who don't send or omit to send KEY_LENGTH
(old versions of us included).

> It'll allow us to save few bytes by omitting attribute for most common cases.

Not worth it.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Apr 2019 14:40:33 -0400

Hi,

Thanks Valery for your comment. My reading of the draft is that it only
focuses on the generation of the nonce and leave the remaining to 4306 [1].
The use of a code points different from 4306 is to indicate the implicit IV
- as opposed to a new transform. In this case, the negotiation of the key
length is left to 4306.  I am inclined to think this is not necessary to
discuss the key length attribute in this draft, but I would like to see
what the other think.

That said, if people strongly think that should be added, I would add the
text from 4306 mentioned below[2].

Yours,
Daniel

[1] The text of the implicit draft:

2 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2>.
Introduction

   Counter-based AES modes of operation such as AES-CTR ([RFC3686
<https://tools.ietf.org/html/rfc3686>]),
   AES-CCM ([RFC4309 <https://tools.ietf.org/html/rfc4309>]), and
AES-GCM ([RFC4106 <https://tools.ietf.org/html/rfc4106>]) require the
   specification of an nonce for each ESP packet.  The same applies for
   ChaCha20-Poly1305 ([RFC7634
<https://tools.ietf.org/html/rfc7634>]).  Currently this nonce is sent
in each
   ESP packet ([RFC4303 <https://tools.ietf.org/html/rfc4303>]).  This
practice is designated in this document
   as "explicit nonce".

[...]

   This document defines how to compute the nonce locally when it is
   implicit.  It also specifies how peers agree with the Internet Key
   Exchange version 2 (IKEv2 - [RFC7296
<https://tools.ietf.org/html/rfc7296>]) on using an implicit IV versus
   an explicit IV.

[2] the text on key length of RFC 4306.

8.4 <https://tools.ietf.org/html/rfc4106#section-8.4>.  Key Length Attribute

   Because the AES supports three key lengths, the Key Length attribute
   MUST be specified in the IKE Phase 2 exchange [RFC2407
<https://tools.ietf.org/html/rfc2407>].  The Key
   Length attribute MUST have a value of 128, 192, or 256.

On Tue, Apr 2, 2019 at 12:52 PM Paul Wouters <[email-masked]> wrote:

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 3 Apr 2019 08:52:31 +0300

Hi Paul,

> (old versions of us included).

I don't buy this argument. There will always be broken implementations
and implementers who don't read the documents. We cannot improve human being.

> > It'll allow us to save few bytes by omitting attribute for most common cases.

I agree that the win is small, but we can get it for free.
After all, implicit IV is intended to be used in situations,
when extra bytes on wire are expensive, so making
IKE SA payload smaller for this particular transforms 
makes sense. But I definitely don't insist.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 3 Apr 2019 09:05:09 +0300

Hi Daniel,

I understand that the draft is only focused on the IV, but since it defines new transforms,

it formally must address key length issue for AES. You can either copy-paste text from RFC 4106 (or 4309),

or add text referencing Section 8.4 of RFC 4106 for GCM and Section 7.4 of RFC 4309 for CCM.

Or alternatively, as I already suggested, you can define default key length and make 

Key Length attribute optional – it will allow to save a couple of bytes for most common cases.

In any cases, I prefer not to put this into Introduction, but instead add a new section,

as it is done in all other transform-defining RFCs.

Regards,

Valery.

From: Daniel Migault [mailto:[email-masked]] 
Sent: Tuesday, April 02, 2019 9:41 PM
To: Paul Wouters
Cc: Valery Smyslov; IPsecME WG
Subject: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi, 

Thanks Valery for your comment. My reading of the draft is that it only focuses on the generation of the nonce and leave the remaining to 4306 [1]. The use of a code points different from 4306 is to indicate the implicit IV - as opposed to a new transform. In this case, the negotiation of the key length is left to 4306.  I am inclined to think this is not necessary to discuss the key length attribute in this draft, but I would like to see what the other think. 

That said, if people strongly think that should be added, I would add the text from 4306 mentioned below[2].  

Yours, 

Daniel

 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2> 2.  Introduction

   Counter-based AES modes of operation such as AES-CTR ([RFC3686 <https://tools.ietf.org/html/rfc3686> ]),
   AES-CCM ([RFC4309 <https://tools.ietf.org/html/rfc4309> ]), and AES-GCM ([RFC4106 <https://tools.ietf.org/html/rfc4106> ]) require the
   specification of an nonce for each ESP packet.  The same applies for
   ChaCha20-Poly1305 ([RFC7634 <https://tools.ietf.org/html/rfc7634> ]).  Currently this nonce is sent in each
   ESP packet ([RFC4303 <https://tools.ietf.org/html/rfc4303> ]).  This practice is designated in this document
   as "explicit nonce".

[...]

   This document defines how to compute the nonce locally when it is
   implicit.  It also specifies how peers agree with the Internet Key
   Exchange version 2 (IKEv2 - [RFC7296 <https://tools.ietf.org/html/rfc7296> ]) on using an implicit IV versus
   an explicit IV.

 <https://tools.ietf.org/html/rfc4106#section-8.4> 8.4.  Key Length Attribute

   Because the AES supports three key lengths, the Key Length attribute
   MUST be specified in the IKE Phase 2 exchange [RFC2407 <https://tools.ietf.org/html/rfc2407> ].  The Key
   Length attribute MUST have a value of 128, 192, or 256.

Not worth it.

Paul

---

From: "Tobias Guggemos" <[email-masked]>
Date: Wed, 3 Apr 2019 09:05:43 +0200

Hey,

I’d prefer not having the key length explicitly defined in this document.

I think, this document should be able to define Implicit IV for any cipher being appropriate to use it.

Currently, that’s AES GCM, CCM and Chacha, but I’d like not to see another document defining the same for every other cipher which might come along.

If this is a formal requirement, can we add a text that the Implicit IV is negotiated the same way as the underlying cipher, with references to the currently defined ones?

e.g.

5.  Initiator Behavior

   An initiator supporting this feature SHOULD propose implicit IV

   algorithms in the Transform Type 1 (Encryption Algorithm)

   Substructure of the Proposal Substructure inside the SA Payload.  

+ The attributes of this Transform Type MUST be equal to the ones defined

+ by the originating algorithms, e.g. key length for AES-CCM [RFC 4106] and

+ AES-GCM [RFC 4309]

   To

   facilitate backward compatibility with non-supporting peers the

   initiator SHOULD also include those same algorithms without Implicit

   IV (IIV) as separate transforms.

>Key Length attribute optional – it will allow to save a couple of bytes for most common cases.

I like this idea, but I don’t think this draft is the right place to do it. 

Maybe an new draft, defining default values for some ciphers, which explicitly allows to omit them in the proposal?

Regards

Tobias

Von: IPsec <[email-masked]> Im Auftrag von Valery Smyslov
Gesendet: Mittwoch, 3. April 2019 08:05
An: 'Daniel Migault' <[email-masked]>; 'Paul Wouters' <[email-masked]>
Cc: 'IPsecME WG' <[email-masked]>
Betreff: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi Daniel,

Regards,

Valery.

Hi, 

Yours, 

Daniel

2 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2> .  Introduction

[...]

8.4 <https://tools.ietf.org/html/rfc4106#section-8.4> .  Key Length Attribute

 

On Tue, Apr 2, 2019 at 12:52 PM Paul Wouters <[email-masked] <mailto:[email-masked]> > wrote:

	

	Not worth it.
	
	Paul
	
	_______________________________________________
	IPsec mailing list
	[email-masked] <mailto:[email-masked]> 
	https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 3 Apr 2019 10:10:06 +0300

In any case I’d like to see an explicit text in the draft saying that

this document only redefines how IV is generated and (non) transmitted,

all the other aspects of applying these transforms are defined

in the relevant RFCs:

ENCR_AES_CCM_8_IIV – from RFC 4309 (for ENCR_AES_GCM_8)

ENCR_AES_GCM_16_IIV – from RFC 4106 (for ENCR_AES_GCM_16)

ENCR_CHACHA20_POLY1305_IIV – from RFC 7634

This is probably obvious, but I prefer to explicitly state this, since it’s a technical

document and it should not leave a space for ambiguity.

Regards,

Valery.

From: Valery Smyslov [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2019 9:05 AM
To: 'Daniel Migault'; 'Paul Wouters'
Cc: 'IPsecME WG'
Subject: RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi Daniel,

Regards,

Valery.

Hi, 

Yours, 

Daniel

 

[...]

 

Not worth it.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 3 Apr 2019 10:13:13 +0300

Hi Tobias,

From: Tobias Guggemos [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2019 10:06 AM
To: 'Valery Smyslov'; 'Daniel Migault'; 'Paul Wouters'
Cc: 'IPsecME WG'
Subject: AW: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hey,

e.g.

5.  Initiator Behavior

+ AES-GCM [RFC 4309]

          OK. And please add some words that all other aspects 

          of applying theses transforms must be taken from 

          the relevant RFCs (explicitly cite which).

   To

          Works for me.

          Regards,

          Valery.

Regards

Tobias

Hi Daniel,

Regards,

Valery.

Hi, 

Yours, 

Daniel

 

[...]

 

Not worth it.

Paul

---

From: "Tobias Guggemos" <[email-masked]>
Date: Wed, 3 Apr 2019 14:58:07 +0200

Hey Valery,

>the relevant RFCs (explicitly cite which).

Do you think the following addresses the comment? I’m not sure if section 5 is the right place for it…

4 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4> .  Implicit IV

   [...]

   o  Extended Sequence Number: the 8 byte Extended Sequence Number of

      the Security Association.  The 4 byte low order bytes are carried

      in the ESP packet.

+  This document solely defines the IV generation of the algorithms defined

+  in [RFC4106], [RFC4309], [RFC7634] or any future algorithms using this 

+  mechanism. Any other aspect of applying those ciphers with the new 

+  Transform Types defined in this document MUST be taken from the 

+  documents defining the use of the algorithms in ESP.

5 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-5> .  Initiator Behavior

+  AES-GCM [RFC 4309]. 

   To

Regards

Tobias

Von: Valery Smyslov <[email-masked]> 
Gesendet: Mittwoch, 3. April 2019 09:13
An: 'Tobias Guggemos' <[email-masked]>; 'Daniel Migault' <[email-masked]>; 'Paul Wouters' <[email-masked]>
Cc: 'IPsecME WG' <[email-masked]>
Betreff: RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi Tobias,

Hey,

e.g.

5.  Initiator Behavior

+ AES-GCM [RFC 4309]

   To

          Works for me.

          Regards,

          Valery.

Regards

Tobias

Von: IPsec <[email-masked] <mailto:[email-masked]> > Im Auftrag von Valery Smyslov
Gesendet: Mittwoch, 3. April 2019 08:05
An: 'Daniel Migault' <[email-masked] <mailto:[email-masked]> >; 'Paul Wouters' <[email-masked] <mailto:[email-masked]> >
Cc: 'IPsecME WG' <[email-masked] <mailto:[email-masked]> >
Betreff: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi Daniel,

Regards,

Valery.

Hi, 

Yours, 

Daniel

 

[...]

 

	

	
	Not worth it.
	
	Paul

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Apr 2019 09:06:07 -0400

Thanks Tobias for proposing some text. I am fine with the text. I do not
think we need to specify the specific transforms
(ENCR_AES_GCM_8, ENCR_AES_GCM_16)  as we are not limited to these
transforms. If everyone is fine with the text and chairs agree to we could
upload a updated version.
Yours,
Daniel

On Wed, Apr 3, 2019 at 8:58 AM Tobias Guggemos <[email-masked]>
wrote:

> 4
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4>.
> Implicit IV
>
>    [...]
>
> 5
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-5>.
> Initiator Behavior
>
>
>
>    IV (IIV) as separate transforms..
>
>
>
> Regards
>
> Tobias
>
>
>
>
>
> *Von:* Valery Smyslov <[email-masked]>
> *Gesendet:* Mittwoch, 3. April 2019 09:13
> *An:* 'Tobias Guggemos' <[email-masked]>; 'Daniel Migault' <
> [email-masked]>; 'Paul Wouters' <[email-masked]>
> *Cc:* 'IPsecME WG' <[email-masked]>
> *Betreff:* RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hi Tobias,
>
>
>
> *From:* Tobias Guggemos [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, April 03, 2019 10:06 AM
> *To:* 'Valery Smyslov'; 'Daniel Migault'; 'Paul Wouters'
> *Cc:* 'IPsecME WG'
> *Subject:* AW: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hey,
>
> I think, this document should be able to define Implicit IV for any cipher
> being appropriate to use it..
>
> Currently, that’s AES GCM, CCM and Chacha, but I’d like not to see another
> document defining the same for every other cipher which might come along.
>
>
>
> If this is a formal requirement, can we add a text that the Implicit IV is
> negotiated the same way as the underlying cipher, with references to the
> currently defined ones?
>
> e.g.
>
>
>
> 5.  Initiator Behavior
>
>
>
> Maybe an new draft, defining default values for some ciphers, which
> explicitly allows to omit them in the proposal?
>
>
>
>           Works for me.
>
>
>
>           Regards,
>
>           Valery.
>
>
>
> Regards
>
> Tobias
>
>
>
> *Von:* IPsec <[email-masked]> *Im Auftrag von *Valery Smyslov
> *Gesendet:* Mittwoch, 3. April 2019 08:05
> *An:* 'Daniel Migault' <[email-masked]>; 'Paul Wouters' <
> [email-masked]>
> *Cc:* 'IPsecME WG' <[email-masked]>
> *Betreff:* Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hi Daniel,
>
>
>
> *From:* Daniel Migault [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, April 02, 2019 9:41 PM
> *To:* Paul Wouters
> *Cc:* Valery Smyslov; IPsecME WG
> *Subject:* Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hi,
>
>
>
> *2
> <https://tools..ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2>**.
> Introduction*
>
>
>
>
>
>    Counter-based AES modes of operation such as AES-CTR ([RFC3686 <https://tools.ietf.org/html/rfc3686>]),
>
>    AES-CCM ([RFC4309 <https://tools..ietf.org/html/rfc4309>]), and AES-GCM ([RFC4106 <https://tools.ietf.org/html/rfc4106>]) require the
>
>    specification of an nonce for each ESP packet..  The same applies for
>
>    ChaCha20-Poly1305 ([RFC7634 <https://tools.ietf.org/html/rfc7634>]).  Currently this nonce is sent in each
>
>    ESP packet ([RFC4303 <https://tools.ietf.org/html/rfc4303>]).  This practice is designated in this document
>
>    as "explicit nonce".
>
> [...]
>
>    Exchange version 2 (IKEv2 - [RFC7296 <https://tools.ietf.org/html/rfc7296>]) on using an implicit IV versus
>
>    an explicit IV.
>
>
>
> *8.4 <https://tools.ietf.org/html/rfc4106#section-8.4>**.  Key Length
> Attribute*
>
>
>
>
>
>    MUST be specified in the IKE Phase 2 exchange [RFC2407 <https://tools..ietf.org/html/rfc2407>].  The Key
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 3 Apr 2019 16:19:25 +0300

Hi Tobias,

I think that with your added text to Section 4, the text about

Key Length attributes in Section 5 becomes unnecessary (since

“all other aspects” includes Key Length too). But it won’t harm.

And I’m not sure it’s worth to mention “any future algorithms using this 

mechanism”. Your draft defines exactly 3 new transforms, if some

future algorithm will be defined using IIV, a new RFC will be needed anyway

to allocate new code point (strictly speaking with Expert Review allocation policy 

you can allocate code points without any document describing their use,

but I don’t think it’s a good practice). So, I’d rather to remove this part.

Otherwise my comment is addressed.

Thank you,

Valery.

From: Tobias Guggemos [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2019 3:58 PM
To: 'Valery Smyslov'; 'Daniel Migault'; 'Paul Wouters'
Cc: 'IPsecME WG'
Subject: AW: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hey Valery,

 

 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4> 4.  Implicit IV

   [...]

      in the ESP packet.

 

 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-5> 5.  Initiator Behavior

+  AES-GCM [RFC 4309]. 

   To

Regards

Tobias

Hi Tobias,

Hey,

e.g.

5.  Initiator Behavior

+ AES-GCM [RFC 4309]

   To

          Works for me.

          Regards,

          Valery.

Regards

Tobias

Hi Daniel,

Regards,

Valery.

Hi, 

Yours, 

Daniel

 

[...]

 

Not worth it.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Apr 2019 11:43:05 -0400

Hi, So the text could be:4
<https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4>.
Implicit IV

   [...]

      in the ESP packet.

+  in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for
ChaCha20-Poly1305.

+  Any other aspect (including the Key Length) of applying those ciphers
with the new

Do we agree ?

Yours,
Daniel

On Wed, Apr 3, 2019 at 9:27 AM Valery Smyslov <[email-masked]>
wrote:

> *From:* Tobias Guggemos [mailto:[email-masked]]
> *Sent:* Wednesday, April 03, 2019 3:58 PM
> being appropriate to use it.
>
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2>**.
> Introduction*
>
>
>
>
>
>    AES-CCM ([RFC4309 <https://tools.ietf.org/html/rfc4309>]), and AES-GCM ([RFC4106 <https://tools.ietf.org/html/rfc4106>]) require the
>
>    MUST be specified in the IKE Phase 2 exchange [RFC2407 <https://tools.ietf.org/html/rfc2407>].  The Key
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 3 Apr 2019 18:47:17 +0300

Fine, thank you!

Nit:

s/including the Key Length/including using the Key Length attribute

From: Daniel Migault [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2019 6:43 PM
To: Valery Smyslov
Cc: Tobias Guggemos; Paul Wouters; IPsecME WG
Subject: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi, 

So the text could be:

   [...]

      in the ESP packet.

+  in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for ChaCha20-Poly1305. 

+  Any other aspect (including the Key Length) of applying those ciphers with the new

Do we agree ?
Yours, 
Daniel

On Wed, Apr 3, 2019 at 9:27 AM Valery Smyslov <[email-masked]> wrote:

Hi Tobias,

Thank you,

Valery.

Hey Valery,

 

   [...]

      in the ESP packet.

 

 

+  AES-GCM [RFC 4309]. 

   To

Regards

Tobias

Hi Tobias,

Hey,

e.g.

5.  Initiator Behavior

+ AES-GCM [RFC 4309]

   To

          Works for me.

          Regards,

          Valery.

Regards

Tobias

Hi Daniel,

Regards,

Valery.

Hi, 

Yours, 

Daniel

 

[...]

 

Not worth it.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Apr 2019 14:34:26 -0400

So the becomes:4

   [...]

      in the ESP packet.

+  Any other aspect (including using the Key Length attribute) of applying
those ciphers with the new

One additional question came to my mind on whether we update the RFC
mentioned above or not.  We could consider our document as an alternate
mechanism to generate the IV of the existing RFC.

Yours,
Daniel

On Wed, Apr 3, 2019 at 11:47 AM Valery Smyslov <[email-masked]>
wrote:

> *From:* Daniel Migault [mailto:[email-masked]]
> *Sent:* Wednesday, April 03, 2019 6:43 PM
> *To:* Valery Smyslov
> *Cc:* Tobias Guggemos; Paul Wouters; IPsecME WG
> 2
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2>.
> Introduction
>
>
>
>
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 4 Apr 2019 08:47:49 +0300

Hi Daniel,

So the becomes:

   [...]

      in the ESP packet.

+  Any other aspect (including using the Key Length attribute) of applying those ciphers with the new

          Yes.

One additional question came to my mind on whether we update the RFC mentioned above or not.  We could consider our document as an alternate mechanism to generate the IV of the existing RFC. 

          No, since you define your own transforms (with own code points) you don’t need to update those RFCs.

          Regards,

          Valery.

Yours, 

Daniel  

On Wed, Apr 3, 2019 at 11:47 AM Valery Smyslov <[email-masked]> wrote:

Fine, thank you!

Nit:

 

Hi, 

So the text could be:

   [...]

      in the ESP packet.

Do we agree ?
Yours, 
Daniel

Hi Tobias,

Thank you,

Valery.

Hey Valery,

 

   [...]

      in the ESP packet.

 

 

+  AES-GCM [RFC 4309]. 

   To

Regards

Tobias

Von: Valery Smyslov < <mailto:[email-masked]> [email-masked]> 
Gesendet: Mittwoch, 3. April 2019 09:13
An: 'Tobias Guggemos' < <mailto:[email-masked]> [email-masked]>; 'Daniel Migault' < <mailto:[email-masked]> [email-masked]>; 'Paul Wouters' < <mailto:[email-masked]> [email-masked]>
Cc: 'IPsecME WG' < <mailto:[email-masked]> [email-masked]>
Betreff: RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi Tobias,

From: Tobias Guggemos [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Wednesday, April 03, 2019 10:06 AM
To: 'Valery Smyslov'; 'Daniel Migault'; 'Paul Wouters'
Cc: 'IPsecME WG'
Subject: AW: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hey,

e.g.

5.  Initiator Behavior

+ AES-GCM [RFC 4309]

   To

          Works for me.

          Regards,

          Valery.

Regards

Tobias

Von: IPsec < <mailto:[email-masked]> [email-masked]> Im Auftrag von Valery Smyslov
Gesendet: Mittwoch, 3. April 2019 08:05
An: 'Daniel Migault' < <mailto:[email-masked]> [email-masked]>; 'Paul Wouters' < <mailto:[email-masked]> [email-masked]>
Cc: 'IPsecME WG' < <mailto:[email-masked]> [email-masked]>
Betreff: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi Daniel,

Regards,

Valery.

From: Daniel Migault [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, April 02, 2019 9:41 PM
To: Paul Wouters
Cc: Valery Smyslov; IPsecME WG
Subject: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

Hi, 

Yours, 

Daniel

 

[...]

 

Not worth it.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Apr 2019 20:55:56 +0300

Valery Smyslov writes:
> > One additional question came to my mind on whether we update the
> > RFC mentioned above or not. We could consider our document as an
> > alternate mechanism to generate the IV of the existing RFC.
> 

I agree on that, and I think the new text is good, please submit new
updated version. 
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Sat, 6 Apr 2019 11:40:50 -0400

Just submitted thank you all for your comments and suggestions!
Yours,
Daniel