Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

From: Daniel Migault <[email-masked]>
Date: Thu, 9 Jun 2016 16:19:58 +0000

Hi,

Please find our new proposal with ESP using implicit IV [1]. We would like to present and discuss it at the next IETF meeting.

We would be happy to have the WG opinion on which you think is the better way to negotiate the implicit IV between two peers. The different options are detailed in section 5 and copy paste here in the email:

"""
   Negotiation of the use of implicit IV can be done in 3 different
   ways:

   o  An IMPLICIT IV Transform Type.  A proposal that contains this
      transform type requires (if accepted) that IPsec use the implicit
      IV and not include an explicit IV in the packets.  To facilitate
      backward compatibility with non-supporting implementations the
      Initiator SHOULD add another proposal that does not include this
      transform type as well as cryptographic suite the Initiator does
      not support the implicit IV.

   o  An IMPLICIT IV Transform ID.  This doubles the number of ENCR
      transform IDs by creating an ENCR_AES_CCM_16_IIV for each
      ENCR_AES_CCM_16.

   o  An IMPLICIT IV Transform Attribute, which would be associated to a
      Transform Type ID, specifying the use of an implicit IV. marks a
      particular ENCR transform as using implicit IVs.  To facilitate
      backward compatibility with non-supporting implementations the
      Initiator SHOULD add another ENCR transform for each algorithm so
      marked.  In other words, for each ENCR_AES_CCM_16 with
      keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16
      with keylength=256 and no IIV attribute.

"""  

[1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 09, 2016 12:12 PM
To: Tobias Guggemos; Yoav Nir; Daniel Migault
Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name:		draft-mglt-ipsecme-implicit-iv
Revision:	00
Title:		Implicit IV for Counter-based Ciphers in IPsec
Document date:	2016-06-09
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
Htmlized:       https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00

Abstract:
   IPsec ESP sends an initialization vector (IV) or nonce in each
   packet, adding 8 or 16 octets.  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, saving 8 octets
   per packet.  This document describes how to do this.

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.

The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Jun 2016 22:42:12 -0400 (EDT)

> Please find our new proposal with ESP using implicit IV [1]. We would like to present and discuss it at the next IETF meeting.

I must understand it wrong...

Aren't these IVs different per ESP packet? And unrelated to IKE
values? How do both parties calculate the IV if it is not send as part
of the packet?

>From what I understand, only part of that comes from IKE (aka the salt
values that are taken from the IKE KEYMAT). As far as I understand, it
still needs to be unpredictable?

If this IV somehow comes from IKE, it might be very tricky for FIPS
certifications, because the security of the ESP IV then depends on
the IKE userland.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Fri, 10 Jun 2016 09:01:33 +0300

Hi, Paul

> certifications, because the security of the ESP IV then depends on

All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP packet.

For all of those algorithms, the respective RFC recommends to use a counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a counter is simpler.

ESP already has a counter - the packet sequence. If you follow the advice in the RFCs the ESP header will look like this:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|               Security Parameters Index (SPI)                 | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                              IV                               | |   
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----

And the Sequence Number and IV fields will hold the exact same number, except that one is 32-bit while the other is 64-bit.

Our draft simply negotiates omitting the IV field since it is redundant.

Hope this helps

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 10 Jun 2016 10:17:50 +0300

Hi Daniel,

a couple of comments. RFC 3686 Section 6 provides design rationale for making an IV explicit.
I think it will be good if your draft also gives some design rationale why you came
to the opposite conclusion (just to give readers an insight why in IoT world
the weight of different factors might change dramatically comparing to "big" world).

> We would be happy to have the WG opinion on which you think is the better way to negotiate the implicit IV between two 
> peers. The different options are detailed in section 5 and copy paste here in the email:
>
> """

The problems with this option is that it adds additional interdependence between
Transforms presenting in the Proposal. We already have this for AEAD
algorithms, which requires them to be placed in a separate Proposal
from non-AEAD ciphers. This complicates both encoders and parses
(I'd rather have separate Transform Type for AEAD ciphers, but that is that).
With new Transform Type which is only applicable to some of Transform IDs
the things become even more complicated for no practical reason.

>      with keylength=256 and no IIV attribute.

These two options are similar in terms of complexity.
I slightly prefer new Transform IDs over an Implicit IV Attribute since
in this case it is very clear from the IANA registry which ciphers
can be used with Implicit IV.

Regards,
Valery.

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Jun 2016 10:15:47 -0400 (EDT)

> ESP already has a counter - the packet sequence. If you follow the advice in the RFCs the ESP header will look like this:

Ok, now I understand. Thanks.

I'm with Valery about using a new algorithm number. The proposal parser
is already pretty ugly as-is without adding more complexity. It also
allows to re-use the existing userland -> kernel infrastructure as no
new options need to be added to that communication layer. Just another
algorithm number.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 10 Jun 2016 17:39:08 +0300

Hi,

The document takes care to not define Implicit IV for AES-CBC, and I 
believe the underlying reason is malleability of the encryption. The 
same would apply to AES-CTR. So I would suggest to:

  * Exclude AES-CTR from this draft, or...
  * Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key 
material. Is that kept intact by the current proposal?

Thanks,

     Yaron

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 10 Jun 2016 09:28:19 -0700

Here are my thoughts on the options for communicating the Implicit IV option in the proposal:

- A new transform type is problematic, as pointed out by Valery and Paul already, because it adds complexity to the proposal structure for configuring and parsing. This seems to be the least desirable option.

- The new transform ID is easy to add to implementations because it is just another value for an existing field. There is a slight downside in needing new ID allocations for what will be essentially a duplicate algorithm, but numbers are cheap. I think this is the easiest option to adopt and pass between implementation layers (userspace, kernel, etc), but once the layer doing encryption is using the value, it will probably want to flatten the information out into the original algorithm value and a flag that the IV is implicit.

- A new transform attribute is attractive as a clean protocol design, since it seems to be the type of information that transform attributes are meant to hold. There aren't many uses of transform attributes currently, so this may add work to protocol parsers. This may require passing the flag for implicit IVs separately throughout the implementation, rather than as part of the transform ID, but I would be willing to do this as an implementer for the sake of a cleaner protocol.

As such, I vote for either option 2 or 3: 2 for ease of implementation, 3 for clean protocol design.

Thanks,
Tommy

> On Jun 9, 2016, at 9:19 AM, Daniel Migault <[email-masked]> wrote:
> 
> Hi,
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Jun 2016 13:00:37 +0300

> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi,
> 
> The document takes care to not define Implicit IV for AES-CBC, and I believe the underlying reason is malleability of the encryption. The same would apply to AES-CTR. So I would suggest to:
> Exclude AES-CTR from this draft, or...
> Better yet, restrict the draft to AEAD algorithms.
> Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key material. Is that kept intact by the current proposal?
> 

Hi, Yaron

AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the confusing terminology:
The 32-bit per-SA value derived from IKE is called “nonce” in RFC 3686 and “salt” in RFC 4106 (thanks for the corrected reference).
The concatenation of 32-bit per-SA value and IV is called “nonce” in RFC 4106 and doesn’t have a name in RFC 3686.
The concatenation of 32-bit per-SA value, IV, and block counter is called “counter block”  in RFC 3686, but isn’t explicitly mentioned in RFC 4106. The GCM spec also calls it “counter block”.

AFAICT it is not malleable like CBC. In CBC the issue was that an attacker knowing the next IV would be able to generate the first block of the next message such that IV xor Block0 would be whatever the attacker wanted. That block would be the input to the encryption function and thus the attacker could force the encryptor to encrypt whatever block it wanted. With counter mode (or GCM or CCM) the attacker has no control on the inputs to the encryption function. That is why RFC 3686 has text similar to the other documents:

                                                               The same
   IV and key combination MUST NOT be used more than once.  The
   encryptor can generate the IV in any manner that ensures uniqueness.
   Common approaches to IV generation include incrementing a counter for
   each packet and linear feedback shift registers (LFSRs).

So I think CTR belongs in this draft as much as the others.

And yes, the GCM salt or the CTR nonce are derived in the same way and used in the same way.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Jun 2016 13:27:45 +0300

I’ve been looking at the history of TLS interop issues. It seems that the one constant is that anything that doesn’t change all the time is surprising, and for anything surprising there are implementations that die on receiving it:
 - If the version field has always been 0x0300 or 0x0301 and somebody suddenly sends 0x0302 some implementation will close the connection even though the spec for 0301 was explicit on how to handle this.
 - If a 16-bit length field describes the ClientHello message that is always under 256 octets, the higher length octet is always zero. When it suddenly became 1 some implementation closed the connection.

So what can we take away from this to IKE? Perhaps the principle of “Don’t be surprising on the Internet”. 

Since the publication of RFC 4306 we’ve added one exchange type, but we negotiate its use so it’s not surprising. We’ve added two payload types, but their use is also negotiated. Same is true for ID types.  A few other extensions assume support on both sides and happily fail otherwise.

We’ve added no transform types and no transform attributes.

The only things that we routinely surprise peers with are new notifications and new algorithms or transform IDs.

So if our main goal is to reduce surprising interoperability failures, we should probably negotiate this with either notifications or transform IDs. The question is, of course, which is uglier: negotiation with notifications, or duplicating transform IDs. I tend to think the former is uglier, but it kind of resembles the way TFC is negotiated or non-first fragments.

Yoav

> On 10 Jun 2016, at 7:28 PM, Tommy Pauly <[email-masked]> wrote:
>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Jun 2016 17:42:51 -0400

On 13/06/16 06:00, Yoav Nir wrote:
>
>> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>   * The 32-bit per-SA value derived from IKE is called “nonce” in RFC
>     3686 and “salt” in RFC 4106 (thanks for the corrected reference).
>   * The concatenation of 32-bit per-SA value and IV is called “nonce” in
>     RFC 4106 and doesn’t have a name in RFC 3686.
>   * The concatenation of 32-bit per-SA value, IV, and block counter is
>     called “counter block”  in RFC 3686, but isn’t explicitly mentioned
>     in RFC 4106. The GCM spec also calls it “counter block”.
>
>
> AFAICT it is not malleable like CBC. In CBC the issue was that an
> attacker knowing the next IV would be able to generate the first block
> of the next message such that IV xor Block0 would be whatever the
> attacker wanted. That block would be the input to the encryption
> function and thus the attacker could force the encryptor to encrypt
> whatever block it wanted. With counter mode (or GCM or CCM) the attacker
> has no control on the inputs to the encryption function. That is why RFC
> 3686 has text similar to the other documents:
>
>                                                                 The same
>     Common approaches to IV generation include *incrementing a counter* for

AES-CTR is potentially malleable by a MITM who can change counter values 
into ones she'd observed before. However since RFC 3686 is very emphatic 
about the need for integrity protection (Sec. 3.3), we should be fine.

Thanks,
	Yaron

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Jun 2016 15:50:41 -0400

Hi Paul,

I hope this has been clarified. In order to clarify this I updated the text
in the intro:

OLD:
This document defines how to compute the nonce locally when it is implicit.
It also specifies how to negotiate this behavior within the Internet Key
Exchange version 2 (IKEv2 - RFC7296).

NEW:

This document defines how to compute the nonce locally when it is implicit.
It also specifies how peers agree with Internet Key Exchange version 2
IKEv2 on using an implicit IV versus an explicit IV

Please let us know if that address your purpose.

BR,
Daniel

On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir <[email-masked]> wrote:

> >> Please find our new proposal with ESP using implicit IV [1]. We would
> like to present and discuss it at the next IETF meeting.
> >
> All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM,
> ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP
> packet.
>
> For all of those algorithms, the respective RFC recommends to use a
> counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead,
> but a counter is simpler.
>
> ESP already has a counter - the packet sequence. If you follow the advice
> in the RFCs the ESP header will look like this:
>
>  0                   1                   2                   3
> And the Sequence Number and IV fields will hold the exact same number,
> except that one is 32-bit while the other is 64-bit.
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Jun 2016 22:56:10 +0300

Hi, Daniel

I think since we didn’t go with some of the wild ideas that would allow implicit IV in CBC, the verb “compute” here is somewhat confusing. We’re pretty much just copying the sequence number. “Compute” implies something a bit more CPU intensive.

Yoav

> On 15 Jun 2016, at 10:50 PM, Daniel Migault <[email-masked]> wrote:
> 
> Hi Paul, 
> 
> I hope this has been clarified. In order to clarify this I updated the text in the intro:
> 
> OLD:
> This document defines how to compute the nonce locally when it is implicit. It also specifies how to negotiate this behavior within the Internet Key Exchange version 2 (IKEv2 - RFC7296).
> 
> NEW:
> 
> This document defines how to compute the nonce locally when it is implicit. It also specifies how peers agree with Internet Key Exchange version 2 IKEv2 on using an implicit IV versus an explicit IV
> 
> 
> On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Paul
> 
> On 10 Jun 2016, at 5:42 AM, Paul Wouters <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Jun 2016 16:00:38 -0400

Hi, Valery,

Thank you for pointing this section. I assume that is section 8 RFC3686. I
will send a new thread to discuss that. I think the motivation is provided
in the introduction, that is reducing the size of the payload, which was
considered as negligible overhead in RFC3686.

In addition RFC3686 specify that the use of an explicit IV instead of an
implicit IV was not based on cryptographic considerations. However, I
propose that the the Security Consideration section refer to the design
section and explain how using the sequence number for the IV impacts the
systems.

For the vote I will come later to sum up the results.

BR,
Daniel

On Fri, Jun 10, 2016 at 3:17 AM, Valery Smyslov <[email-masked]> wrote:

>> We would be happy to have the WG opinion on which you think is the better
>> way to negotiate the implicit IV between two peers. The different options
>> are detailed in section 5 and copy paste here in the email:
>>
>> """
>> URL:
>> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
>> Htmlized:
>> https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00
>>
>>
>> Abstract:
>> 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.
>>
>> The IETF Secretariat
>>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Jun 2016 16:14:09 -0400

Hi Yaron,

Thanks Yaron for the comments so I updated my local copy replacing RFC4104
by RFC4106 ;-)
I also assume that leaving AES-CTR is fine, and so keep it in the draft.

In the first version of the draft we described a way to have an implicit IV
with AES-CBC. It was based on an additional key derivation for each
direction and the IV was the sequence number encrypted with the key.
During the presentation, we agreed that the additional complexity would not
worth. The reason for that text is to make it clear that would be feasible.

BR,
Daniel

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Jun 2016 16:42:48 -0400

Hi,

Regarding the negotiation of the use of the implicit IV three ways have
been proposed. Currently it seems that the consensus is more encline to
define Transform IDs. However, it has been raised that Transform Attributes
might be a better protocol design choice.

I would like to understand if there are any guidance whether using
attributes is preferred to ID or vice versa and if there is any preference
in using  IMPLICIT IV Transform ID versus an IMPLICIT IV Transform
Attribute.

Here is a summary of the comments we received on the different ways to
negotiate the use of the implicit IV.

   - a) IMPLICIT Transform Type seems to over complexify the the management
   of proposals.
   - b) IMPLICIT IV Transform ID seems the easiest way to move forward. In
   addition, IKEv2 is known to behave properly with new Transform IDs.
   - c) IMPLICIT IV Transform Attribute requires additional parsing. This
   is something that is not widely used outside key sizes. This solution might
   be preferred if it is considered a better architecture design than b).

   BR,
Daniel

On Wed, Jun 15, 2016 at 4:14 PM, Daniel Migault <[email-masked]

> In the first version of the draft we described a way to have an implicit
> IV with AES-CBC. It was based on an additional key derivation for each

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Jun 2016 16:49:38 -0400

Hi Yoav,

You are right. Would the word "generate" more appropriated ?

OLD:

This document defines how to compute the nonce locally when it is implicit.
It also specifies how peers agree with Internet Key Exchange version 2
IKEv2 on using an implicit IV versus an explicit IV.

NEW:

This document defines how to generate the nonce locally when it is
implicit. It also specifies how peers agree with Internet Key Exchange
version 2 IKEv2 on using an implicit IV versus an explicit IV

BR,
Daniel

On Wed, Jun 15, 2016 at 3:56 PM, Yoav Nir <[email-masked]> wrote:

> Hi, Daniel
>
> I think since we didn’t go with some of the wild ideas that would allow
> implicit IV in CBC, the verb “compute” here is somewhat confusing. We’re
> pretty much just copying the sequence number. “Compute” implies something a
> bit more CPU intensive.
>
> Yoav
>
> This document defines how to compute the nonce locally when it is
> implicit. It also specifies how to negotiate this behavior within the
> Internet Key Exchange version 2 (IKEv2 - RFC7296).
>
> NEW:
>
> This document defines how to compute the nonce locally when it is
> implicit. It also specifies how peers agree with Internet Key Exchange
> version 2 IKEv2 on using an implicit IV versus an explicit IV
>
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Jun 2016 17:00:16 -0400 (EDT)

> You are right. Would the word "generate" more appropriated ?

"obtain" ?

Or just reveal your "secret" and state "is taken from the ESP sequence number".

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 17 Jun 2016 16:41:48 +0300

Daniel Migault writes:
> Regarding the negotiation of the use of the implicit IV three ways have been
> proposed. Currently it seems that the consensus is more encline to define
> Transform IDs. However, it has been raised that Transform Attributes might be
> a better protocol design choice.

My personal preference is for Transform IDs. 

> I would like to understand if there are any guidance whether using attributes
> is preferred to ID or vice versa and if there is any preference in using 
> IMPLICIT IV Transform ID versus an IMPLICIT IV Transform Attribute.

Both with Transform IDs and Transform Attributes you need to duplicate
each cipher support things. The payload would be either:

 SA Payload
 |
 +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
 |   |            7 transforms,      SPI = 0x052357bb )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   |     +-- Attribute ( Key Length = 128 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   |     +-- Attribute ( Key Length = 192 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   |     +-- Attribute ( Key Length = 256 )
 |   |
 |   +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
 |   +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
 |   +-- Transform ESN ( Name = ESNs )
 |   +-- Transform ESN ( Name = No ESNs )
 |
 +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
     |            6 transforms,      SPI = 0x35a1d6f2 )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
     |     +-- Attribute ( Key Length = 128 )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
     |     +-- Attribute ( Key Length = 256 )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV )
     |     +-- Attribute ( Key Length = 128 )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV )
     |     +-- Attribute ( Key Length = 256 )
     |
     +-- Transform ESN ( Name = ESNs )
     +-- Transform ESN ( Name = No ESNs )

Or:

 SA Payload
 |
 +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
 |   |            7 transforms,      SPI = 0x052357bb )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   |     +-- Attribute ( Key Length = 128 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   |     +-- Attribute ( Key Length = 192 )
 |   |
 |   +-- Transform ENCR ( Name = ENCR_AES_CBC )
 |   |     +-- Attribute ( Key Length = 256 )
 |   |
 |   +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
 |   +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
 |   +-- Transform ESN ( Name = ESNs )
 |   +-- Transform ESN ( Name = No ESNs )
 |
 +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
     |            6 transforms,      SPI = 0x35a1d6f2 )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
     |     +-- Attribute ( Key Length = 128 )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
     |     +-- Attribute ( Key Length = 256 )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
     |     +-- Attribute ( Key Length = 128 )
     |     +-- Attribute ( Implicit = Yes )
     |
     +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
     |     +-- Attribute ( Key Length = 256 )
     |     +-- Attribute ( Implicit = Yes )
     |
     +-- Transform ESN ( Name = ESNs )
     +-- Transform ESN ( Name = No ESNs )

where missing Implicit would mean same as Implicit = No.

The Transform ID version provides more compact encoding, and I think
it is cleaner.

If transform attribute version is used, that would provide easy way to
expand this for every cipher we have, i.e. including
ENCR_CAMELLIA_CCM, i.e. if we just say it is allowed for
ENCR_CAMELLIA_CCM too, then it can use it. For the Transform ID option
we need to allocate separate ID for ENCR_CAMELLIA_CCM_IIV to allow it
using implicit IV. 

Transform IDs are fairly cheap, and I think it is better that we
explictly mention which ciphers can use this, and doing this by
allocating separate number for them is clean way of indicating that.
Otherwise we need table listing which attributes are allowed with
which cipher...
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Fri, 17 Jun 2016 14:02:06 -0400

Hi Tero,

Thank you for the feed back, my understanding is that we have a a consensus
that Transform ID is the preferred way. I will update the draft accordingly
and post a new version next week.

BR,
Daniel

On Fri, Jun 17, 2016 at 9:41 AM, Tero Kivinen <[email-masked]> wrote:

> been
> attributes