Subject: [lamps] Problems with the current ALGORITHM information object class

From: "Erik Andersen" <[email-masked]>
Date: Mon, 11 May 2020 09:05:11 +0200

In our work with IEC 62351-4 and X.510 we have identified a limitation with
the current ALGORITHM information object class. The current definition is 

ALGORITHM ::= CLASS {

  &Type         OPTIONAL,

  &id           OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {

  [PARMS        &Type]

  IDENTIFIED BY &id }

The PARM field is used for defining parameters associated with the
algorithms. However, the parameters are of two types:

1.       Parameters that provide additional information about the procedure
to be applied according to the algorithm. An example is ecPublicKey, where
the parameter value is the elliptic curve to be used. 

2.       Parameters that specified the syntax of the value to be used when
the algorithm is deployed. An example is the AES algorithms that require a
value of the parameter transferred together with the encrypted data.

This causes problems when negotiating the use of algorithms. When specifying
ecPublicKey algorithms in such negotiation, the parameter value is relevant.
When specifying AES-CBC in such a negotiation, the random value of some
InitializationVector is not relevant. This make algorithm negotiation
cumbersome.

We have therefore suggested to extend the ALGORITHM information object class
in the following way.

ALGORITHM ::= CLASS {

  &Type         OPTIONAL,

  &DynParms     OPTIONAL,

  &id           OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {

  [PARMS        &Type]

  [DYN-PARMS    &DynParms]

  IDENTIFIED BY &id }

A suggested update to the ALGORITHM information object class is attached. It
also includes three derivative parameterized data types. By using those data
types it has been possible to define the wrapper protocol without "hard
coding" specific algorithm details, e.g., we have avoided a specific
component for an initialization vector. This has allowed different
cryptographic algorithms to be used for different communication instances
make life a little more difficult for adversaries.  

Certain algorithms have to be redefined, which could cause some negative
reactions. As an example the aes256-CBC algorithm must be changed from

aes256-CBC ALGORITHM ::= { 

  PARMS         AES-InitializationVector

  IDENTIFIED BY { aes 42 } }

To 

aes256-CBC ALGORITHM ::= { 

  DYN-PARMS       AES-InitializationVector

  IDENTIFIED BY { <some OID> } }

However, most algorithms do not need to be modified.

The current version of X.510 may be found at
https://www.dropbox.com/s/i7mizfvoy9uo21x/x510.docx?dl=0.

Any comments?

Best regards,

Erik

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 May 2020 12:34:56 -0400

If both parameter types are present, then interoperability will be gravely impacted.

Russ

> On May 11, 2020, at 3:05 AM, Erik Andersen <[email-masked]> wrote:
> 
> In our work with IEC 62351-4 and X.510 we have identified a limitation with the current ALGORITHM information object class. The current definition is 
>  
> ALGORITHM ::= CLASS {
>   &Type         OPTIONAL,
> The PARM field is used for defining parameters associated with the algorithms. However, the parameters are of two types:
>  
> 1.       Parameters that provide additional information about the procedure to be applied according to the algorithm. An example is ecPublicKey, where the parameter value is the elliptic curve to be used. 
> 2.       Parameters that specified the syntax of the value to be used when the algorithm is deployed. An example is the AES algorithms that require a value of the parameter transferred together with the encrypted data.
>  
> This causes problems when negotiating the use of algorithms. When specifying  ecPublicKey algorithms in such negotiation, the parameter value is relevant. When specifying AES-CBC in such a negotiation, the random value of some InitializationVector is not relevant. This make algorithm negotiation cumbersome.
>  
> We have therefore suggested to extend the ALGORITHM information object class in the following way.
>  
> ALGORITHM ::= CLASS {
>   &Type         OPTIONAL,
>   &DynParms     OPTIONAL,
> A suggested update to the ALGORITHM information object class is attached. It also includes three derivative parameterized data types. By using those data types it has been possible to define the wrapper protocol without “hard coding” specific algorithm details, e.g., we have avoided a specific component for an initialization vector. This has allowed different cryptographic algorithms to be used for different communication instances make life a little more difficult for adversaries.  
>  
> Certain algorithms have to be redefined, which could cause some negative reactions. As an example the aes256-CBC algorithm must be changed from
>  
> The current version of X.510 may be found at https://www.dropbox.com/s/i7mizfvoy9uo21x/x510.docx?dl=0 <https://www.dropbox.com/s/i7mizfvoy9uo21x/x510.docx?dl=0>.
>  
> Any comments?
>  
> Best regards,
>  
> Erik
>  
>  
>  
>  
>  
>  
> <algorithms.docx>_______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 12 May 2020 14:57:04 +0200

Hi Russ,

The problem was identified when a vendor was implementing IEC 62351-4, where we were faced with the question: When negotiating e.g., symmetric key algorithm, should we just specify the OID or should we also include the parameters. The answer is that sometimes you should only use the OID and in other cases you will also need to include the parameters. In some other cases, like aes256-GCM, you shall include part of the parameter.  What do you then tell the implementor? 

aes256-GCM is an example with a mixture of parameters.:

aes256-GCM ALGORITHM ::= {

  PARMS         GCMParameters

  IDENTIFIED BY id-aes256-GCM }

GCMParameters ::= SEQUENCE {

  aes-nonce   OCTET STRING, -- recommended size is 12 octets

  aes-ICVlen  AES-GCM-ICVlen DEFAULT 12 }

AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)

An alternative algorithm should be defined as:

newAes256-GCM ALGORITHM ::= {

  PARMS         AES-GCM-ICVlen DEFAULT 12,

  DYN-PARMS     OCTET STRING

  IDENTIFIED BY <some other OID> }

Sure, there could be an interworking problem, but it can be handled. Implementations of a standard specifying the original algorithm will still interwork. Implementations of a standard specifying the modified algorithm will also interwork.

For the sake of IEC 62351-4 and X.510, we need a solution. We can either do it unilateral or we can find a common solution, like who defines the alternative algorithms and allocate new OIDs..

Erik

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: 11 May 2020 18:35
To: Erik Andersen <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: Re: [lamps] Problems with the current ALGORITHM information object class

Russ

On May 11, 2020, at 3:05 AM, Erik Andersen <[email-masked] <mailto:[email-masked]> > wrote:

ALGORITHM ::= CLASS {

  &Type         OPTIONAL,

WITH SYNTAX {

  [PARMS        &Type]

  IDENTIFIED BY &id }

ALGORITHM ::= CLASS {

  &Type         OPTIONAL,

  &DynParms     OPTIONAL,

WITH SYNTAX {

  [PARMS        &Type]

  [DYN-PARMS    &DynParms]

  IDENTIFIED BY &id }

To 

The current version of X.510 may be found at  <https://www.dropbox.com/s/i7mizfvoy9uo21x/x510.docx?dl=0> https://www.dropbox.com/s/i7mizfvoy9uo21x/x510.docx?dl=0.

Any comments?

Best regards,

Erik

 

<algorithms.docx>_______________________________________________
Spasm mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/spasm> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 May 2020 10:18:48 -0400

If I was going to make a change that was not backward compatible, that is not the one that I would pick.  In my view, a better answer would be:

aes256-GCM-icv12 ALGORITHM ::= {
  PARMS         GCMNonce
  IDENTIFIED BY aes256-GCM-icv12 }

aes256-GCM-icv13 ALGORITHM ::= {
  PARMS         GCMNonce
  IDENTIFIED BY aes256-GCM-icv13 }

aes256-GCM-icv14 ALGORITHM ::= {
  PARMS         GCMNonce
  IDENTIFIED BY aes256-GCM-icv14 }

aes256-GCM-icv15 ALGORITHM ::= {
  PARMS         GCMNonce
  IDENTIFIED BY aes256-GCM-icv15 }

aes256-GCM-icv16 ALGORITHM ::= {
  PARMS         GCMNonce
  IDENTIFIED BY aes256-GCM-icv16 }

GCMNonce ::= OCTET STRING  -- recommended size is 12 octets

However, I do not advocate a change that breaks  backward compatibiliy.

Russ

> On May 12, 2020, at 8:57 AM, Erik Andersen <[email-masked]> wrote:
> 
> Hi Russ,
>  
> From: Spasm <[email-masked] <mailto:[email-masked]>> On Behalf Of Russ Housley
> Sent: 11 May 2020 18:35
> To: Erik Andersen <[email-masked] <mailto:[email-masked]>>
> Cc: LAMPS <[email-masked] <mailto:[email-masked]>>
>> On May 11, 2020, at 3:05 AM, Erik Andersen <[email-masked] <mailto:[email-masked]>> wrote:
>>  
> _______________________________________________
> Spasm mailing list

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 12 May 2020 14:56:29 +0000

*   However, I do not advocate a change that breaks  backward compatibiliy.

  *   Sure, there could be an interworking problem, but it can be handled. Implementations of a standard specifying the original algorithm will still interwork. Implementations of a standard specifying the modified algorithm will also interwork.

So algorithms that want to use the new constructs, *even if they are the same such as AES 128 GCM* will use a new OID?  If so, that’s okay with me.

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 May 2020 11:00:12 -0400

> On May 12, 2020, at 10:56 AM, Salz, Rich <[email-masked]> wrote:
> 
>  

New OIDs would be needed in my suggestions, otherwise there would be confusion about the parameter structure.

Russ

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 12 May 2020 17:58:48 +0200

Thanks for your replies. We have OID structure that potentially could be used: { joint-iso-itu-t ds(5) algo(42) }. This gives rather short OIDs, although a couple of more levels will be needed for organizing the OIDs in a structured way. 

Erik

From: Russ Housley <[email-masked]> 
Sent: 12 May 2020 17:00
To: Rich Salz <[email-masked]>
Cc: Erik Andersen <[email-masked]>; LAMPS <[email-masked]>
Subject: Re: [lamps] Problems with the current ALGORITHM information object class

On May 12, 2020, at 10:56 AM, Salz, Rich <[email-masked] <mailto:[email-masked]> > wrote:

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 12 May 2020 16:20:29 +0000

Just to make it clear since I’m not sure I understood your last note:  you will not re-use OID’s already defined that use the older syntax, but will define new OID’s for algorithms that want to use the new parameter clarifications, even if the mechanism is the same?

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 12 May 2020 18:25:43 +0200

Right, to avoid interworking problems

Erik

From: Spasm <[email-masked]> On Behalf Of Salz, Rich
Sent: 12 May 2020 18:20
To: Erik Andersen <[email-masked]>; 'Russ Housley' <[email-masked]>
Cc: 'LAMPS' <[email-masked]>
Subject: Re: [lamps] Problems with the current ALGORITHM information object class