Subject: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

From: Mike Jones <[email-masked]>
Date: Fri, 04 Dec 2015 18:16:14 -0800

The external_aad feature is one not found in JOSE, CMS, XMLDSIG, or other commonly used cryptographic formats.  While I am satisfied with the resolution of issue #16 keeping this feature because of the discussions about the CoAP use cases that occurred in Yokohama, I still would like to see the common case that doesn't use it simplified.

Currently, the sig_structure contains [ body_protected, sign_protected, external_aad, payload ].  I request that this be reordered to [ body_protected, sign_protected, payload, external_aad ] and the external_aad array element be specified to be not present when no external_aad value is supplied, so that in the no-external_aad case, the sig_structure value becomes  [ body_protected, sign_protected, payload ].  It's no harder for the code to omit it than to include a zero-length binary value, as currently specified.  And the code still signs the whole array - it's just that the array can have either 4 or 3 elements.

Similarly, please revise the hmac_structure and enc_structure, placing external_aad at the end and making its presence optional.

---
Reply to this email directly or view it on GitHub:
https://github.com/cose-wg/cose-issues/issues/48

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 8 Dec 2015 13:28:40 -0800

I do not believe that invoking security is incorrect in this instance.  The statement that security issues tend to arise on parsing is not something I would accept as a given.  I have probably seen just as many or more problems with building strings, random number generation, timing attacks as I have seen parsing errors.   I don’t think that is a supportable proposition.

You and I have different ideas on what it means to “keep things simple”.  For me, one way of doing things without options is always simpler and less prone to error.  Thus to me having a fixed array is the simpler option.  It does not matter if the specific implementation does or does not support external aad, creating the one additional field in the array is not the same burden as the same thing is going to be for those implementations that do implement the external aad feature.  Making it optional introduces a new state into the system of a zero length aad which is different from no aad.

Again in my opinion – the current version is simpler that what you are proposing.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2015 12:39 PM
To: cose-wg/cose-issues <[email-masked]>
Cc: Jim Schaad <[email-masked]>
Subject: Re: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

Invoking security seems incorrect and overstated here. These values are never parsed - which is when security issues tend to arise. They are just created internally and then used as serialized byte array inputs to cryptographic operations. There is no security problem with having both 3-member and 4-member array values for this intermediate temporary result.

Please capitalize on this opportunity to "keep simple things simple" - one of the working group principles stated by the chairs on slide 22 of their opening presentation at https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. Especially in light of the fact that many implementations won't need support for external_aad, per issue #50 <https://github.com/cose-wg/cose-issues/issues/50> , please make these implementations simpler by making the presence of the external_aad array member optional.

—
Reply to this email directly or view it on GitHub <https://github.com/cose-wg/cose-issues/issues/48#issuecomment-163011143> .

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Dec 2015 22:54:56 +0000

Your way has conditional logic for constructing the data structures depending upon whether an external_aad value is supplied.  So does mine.  So both have “two ways of doing things” – not one way.  The difference is only whether a zero-length field is supplied or whether it’s omitted, which is pretty much equivalent from a security and timing perspective.

You seem worried about implementation errors, which I agree is often a valid concern.  The good news in this case is that incorrect implementations will generate the wrong signature or HMAC value, causing the implementation to fail during interop testing, well before it’s ever deployed.  Normal testing/debugging will catch this.

The additional simplification that my proposal enables is that an implementation can have zero code about external_aad if it’s not supported, where with your representation, the implementation still has to have code to insert the unnecessary and unused array value.

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, December 8, 2015 1:29 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: RE: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

Jim

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, December 08, 2015 12:39 PM
To: cose-wg/cose-issues <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Subject: Re: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

Please capitalize on this opportunity to "keep simple things simple" - one of the working group principles stated by the chairs on slide 22 of their opening presentation at https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. Especially in light of the fact that many implementations won't need support for external_aad, per issue #50<https://github.com/cose-wg/cose-issues/issues/50>, please make these implementations simpler by making the presence of the external_aad array member optional.

—
Reply to this email directly or view it on GitHub<https://github.com/cose-wg/cose-issues/issues/48#issuecomment-163011143>.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 8 Dec 2015 15:20:54 -0800

From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2015 2:55 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: RE: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

No – I do not have any logic about adding the value.  I initialize my environment to be a zero length aad value and always add it to the computation.  If we pick up your change then I  would have to add logic into the system to deal with the presence or lack of it.  Similarly if there is no support at all for external add value there is no conditions – a zero length bstring (i.e one byte) is always added to the value computed.

This is simpler than the logic your version would require me to implement.

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]] 
Sent: Tuesday, December 8, 2015 1:29 PM
To: Mike Jones <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2015 12:39 PM
To: cose-wg/cose-issues <[email-masked] <mailto:[email-masked]> >
Cc: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Subject: Re: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

—

---

From: Brian Campbell <[email-masked]>
Date: Wed, 9 Dec 2015 10:50:45 -0700

I dare say that simplicity is in the eye of the beholder here. Depending on
one's perspective, it's quite reasonable to argue that either approach is
simpler.

What's less subjective is the matter of message size. Using a 3 element
array when there's no external aad does result in a smaller message for
that arguably common case. It's only one byte smaller but it is smaller and
even a single byte is meaningful when the amount of overhead being
discussed is in the 10-20 byte neighborhood -
http://www.ietf.org/mail-archive/web/cose/current/msg00850.html .

On Tue, Dec 8, 2015 at 4:20 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Mike Jones [mailto:[email-masked]]
> *Sent:* Tuesday, December 08, 2015 2:55 PM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [cose-issues] Move external_aad to the end of structures
> using it and make its presence optional (#48)
>
>
>
> Your way has conditional logic for constructing the data structures
> depending upon whether an external_aad value is supplied.  So does mine.
> So both have “two ways of doing things” – not one way.  The difference is
> only whether a zero-length field is supplied or whether it’s omitted, which
> is pretty much equivalent from a security and timing perspective.
>
>
>
> No – I do not have any logic about adding the value.  I initialize my
> environment to be a zero length aad value and always add it to the
> computation.  If we pick up your change then I  would have to add logic
> into the system to deal with the presence or lack of it.  Similarly if
> there is no support at all for external add value there is no conditions –
> a zero length bstring (i.e one byte) is always added to the value computed.
>
>
>
> You seem worried about implementation errors, which I agree is often a
> valid concern.  The good news in this case is that incorrect
> implementations will generate the wrong signature or HMAC value, causing
> the implementation to fail during interop testing, well before it’s ever
> deployed.  Normal testing/debugging will catch this.
>
>
>
> The additional simplification that my proposal enables is that an
> implementation can have zero code about external_aad if it’s not supported,
> where with your representation, the implementation still has to have code
> to insert the unnecessary and unused array value.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Jim Schaad [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Tuesday, December 8, 2015 1:29 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [cose-issues] Move external_aad to the end of structures
> using it and make its presence optional (#48)
>
>
>
> I do not believe that invoking security is incorrect in this instance.
> The statement that security issues tend to arise on parsing is not
> something I would accept as a given.  I have probably seen just as many or
> more problems with building strings, random number generation, timing
> attacks as I have seen parsing errors.   I don’t think that is a
> supportable proposition.
>
>
>
> You and I have different ideas on what it means to “keep things simple”.
> For me, one way of doing things without options is always simpler and less
> prone to error.  Thus to me having a fixed array is the simpler option.  It
> does not matter if the specific implementation does or does not support
> external aad, creating the one additional field in the array is not the
> same burden as the same thing is going to be for those implementations that
> do implement the external aad feature.  Making it optional introduces a new
> state into the system of a zero length aad which is different from no aad.
>
>
>
> *From:* Mike Jones [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, December 08, 2015 12:39 PM
> *To:* cose-wg/cose-issues <[email-masked]>
> *Cc:* Jim Schaad <[email-masked]>
> *Subject:* Re: [cose-issues] Move external_aad to the end of structures
> using it and make its presence optional (#48)
>
>
>
> Invoking security seems incorrect and overstated here. These values are
> never parsed - which is when security issues tend to arise. They are just
> created internally and then used as serialized byte array inputs to
> cryptographic operations. There is no security problem with having both
> 3-member and 4-member array values for this intermediate temporary result.
>
> Please capitalize on this opportunity to "keep simple things simple" - one
> of the working group principles stated by the chairs on slide 22 of their
> opening presentation at
> https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf.
> Especially in light of the fact that many implementations won't need
> support for external_aad, per issue #50
> <https://github.com/cose-wg/cose-issues/issues/50>, please make these
> implementations simpler by making the presence of the external_aad array
> member optional.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/cose-wg/cose-issues/issues/48#issuecomment-163011143>.[image:
> Image removed by sender.]
>
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 9 Dec 2015 10:14:10 -0800

Given that this field is never transmitted across the wire, there is no difference in message size.

From: Brian Campbell [mailto:[email-masked]] 
Sent: Wednesday, December 09, 2015 9:51 AM
To: Jim Schaad <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

I dare say that simplicity is in the eye of the beholder here. Depending on one's perspective, it's quite reasonable to argue that either approach is simpler. 

What's less subjective is the matter of message size. Using a 3 element array when there's no external aad does result in a smaller message for that arguably common case. It's only one byte smaller but it is smaller and even a single byte is meaningful when the amount of overhead being discussed is in the 10-20 byte neighborhood - http://www.ietf.org/mail-archive/web/cose/current/msg00850.html . 

On Tue, Dec 8, 2015 at 4:20 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

From: Mike Jones [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, December 08, 2015 2:55 PM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48)

                                                                -- Mike

Jim

—

_______________________________________________
COSE mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

---

From: Brian Campbell <[email-masked]>
Date: Wed, 9 Dec 2015 11:27:11 -0700

My mistake, apologies.

On Wed, Dec 9, 2015 at 11:14 AM, Jim Schaad <[email-masked]> wrote:

> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Wednesday, December 09, 2015 9:51 AM
> *Cc:* Mike Jones <[email-masked]>; [email-masked]
> *Subject:* Re: [COSE] [cose-issues] Move external_aad to the end of
> structures using it and make its presence optional (#48)
>
>
>
> I dare say that simplicity is in the eye of the beholder here. Depending
> on one's perspective, it's quite reasonable to argue that either approach
> is simpler.
>
> <https://github.com/cose-wg/cose-issues/issues/48#issuecomment-163011143>.
>
>

---

From: Jim Schaad <[email-masked]>
Date: Sat, 12 Dec 2015 11:39:07 -0800

Beauty is in the eye of the beholder on this in terms of what is easier.

However, while putting something other than the body last works for signatures with appendix schemes, it will not work correctly for signature recovery schemes.  For such schemes the body needs to be last so that it is the part that is going to be recovered.  Otherwise, there is no difference in the size of the message that is being transmitted.  Recovering the external AAD information which is not transmitted does not help reduce the message size.

---
Reply to this email directly or view it on GitHub:
https://github.com/cose-wg/cose-issues/issues/48#issuecomment-164178245