Subject: Re: [COSE] Issue #51 - make "alg" field optional

From: Francesca Palombini <[email-masked]>
Date: Fri, 5 Feb 2016 11:03:59 +0000

Hi Jim and all,

We are not against having this relaxation discussed in an appendix instead of in the core of the draft, as long as it is in the COSE document. We will define in (the next version of) OSCOAP exactly how the external_aad is constructed (and that it includes alg).

Between your choices, we would prefer to have the discussion about optional alg in an appendix of the COSE draft (that we can refer to) rather than defining it ourselves in the OSCOAP draft. Defining the alg to be optional in OSCOAP while having it mandatory in COSE would create a discrepancy between the two documents, and I believe it would create confusion for future implementers.

I understand you do not want to leave the door open for misinterpretation, and prefer to have a strong "default" behavior that cannot be misunderstood and would not create security issues derived by "common use" ; on the other hand I don't understand how could the sentence "either you include the algorithm in the (protected part of the) message or in the externally supplied aad" be misunderstood. Why wouldn't the restriction "no alg --> alg in external_aad" be enough in the COSE document, leaving the task to exactly define the external_aad to the application?

I am confused here because it looks to me as if you would rather accept discrepancies between COSE and application spec rather than mandate that "the alg must be included in the external_aad". In my opinion the first would create more confusion than the second.  But I'm interested in hearing the opinion of the group of course.

tl;dr we (OSCOAP) agree with having this in an appendix if your prefer. Wondering why mandating alg in external_aad wouldn't be "explicit enough".

Francesca

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 5 Feb 2016 22:40:39 +0100

Hi Francesca and all,

I might have missed some previous discussion but I don´t get why it is
better to have the alg parameter in external_aad than as part of the COSE
message. When I read your reply I interpret it as, alg is mandatory, but
you are allowed to put it in the COSE message or in the external_aad. What
benefit am I missing?

Regards
//Samuel

On Fri, Feb 5, 2016 at 12:03 PM, Francesca Palombini <
[email-masked]> wrote:

> Hi Jim and all,
>
>
>
> We are not against having this relaxation discussed in an appendix instead
> of in the core of the draft, as long as it is in the COSE document. We will
> define in (the next version of) OSCOAP exactly how the external_aad is
> constructed (and that it includes alg).
>
>
>
> Between your choices, we would prefer to have the discussion about
> optional alg in an appendix of the COSE draft (that we can refer to) rather
> than defining it ourselves in the OSCOAP draft. Defining the alg to be
> optional in OSCOAP while having it mandatory in COSE would create a
> discrepancy between the two documents, and I believe it would create
> confusion for future implementers.
>
>
>
> I understand you do not want to leave the door open for misinterpretation,
> and prefer to have a strong “default” behavior that cannot be misunderstood
> and would not create security issues derived by “common use” ; on the other
> hand I don’t understand how could the sentence “either you include the
> algorithm in the (protected part of the) message or in the externally
> supplied aad” be misunderstood. Why wouldn’t the restriction “no alg -->
> alg in external_aad” be enough in the COSE document, leaving the task to
> exactly define the external_aad to the application?
>
>
>
> I am confused here because it looks to me as if you would rather accept
> discrepancies between COSE and application spec rather than mandate that
> “the alg must be included in the external_aad”. In my opinion the first
> would create more confusion than the second.  But I’m interested in hearing
> the opinion of the group of course.
>
>
>
> tl;dr we (OSCOAP) agree with having this in an appendix if your prefer.
> Wondering why mandating alg in external_aad wouldn’t be “explicit enough”.
>
>
>
> Francesca
>
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 6 Feb 2016 18:31:14 -0800

From: Francesca Palombini [mailto:[email-masked]] 
Sent: Friday, February 05, 2016 3:04 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] Issue #51 - make "alg" field optional

Hi Jim and all,

Between your choices, we would prefer to have the discussion about optional
alg in an appendix of the COSE draft (that we can refer to) rather than
defining it ourselves in the OSCOAP draft. Defining the alg to be optional
in OSCOAP while having it mandatory in COSE would create a discrepancy
between the two documents, and I believe it would create confusion for
future implementers.

I understand you do not want to leave the door open for misinterpretation,
and prefer to have a strong "default" behavior that cannot be misunderstood
and would not create security issues derived by "common use" ; on the other
hand I don't understand how could the sentence "either you include the
algorithm in the (protected part of the) message or in the externally
supplied aad" be misunderstood. Why wouldn't the restriction "no alg --> alg
in external_aad" be enough in the COSE document, leaving the task to exactly
define the external_aad to the application?

I am confused here because it looks to me as if you would rather accept
discrepancies between COSE and application spec rather than mandate that
"the alg must be included in the external_aad". In my opinion the first
would create more confusion than the second.  But I'm interested in hearing
the opinion of the group of course.

tl;dr we (OSCOAP) agree with having this in an appendix if your prefer.
Wondering why mandating alg in external_aad wouldn't be "explicit enough".

[JLS] The issue for me is that even if we mandate that an application must
create an external_aad structure and include it, a generic application might
not do this if it was going to be slightly mis-behaved.  Making the
application need to do this explicitly puts the onus on the application to
get it right and not be implicit from the COSE spec.

Jim

Francesca

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 6 Feb 2016 18:33:12 -0800

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Friday, February 05, 2016 1:41 PM
To: Francesca Palombini <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] Issue #51 - make "alg" field optional

Hi Francesca and all,

I might have missed some previous discussion but I don´t get why it is better to have the alg parameter in external_aad than as part of the COSE message. When I read your reply I interpret it as, alg is mandatory, but you are allowed to put it in the COSE message or in the external_aad. What benefit am I missing?

[JLS]  External_aad  is constructed locally by the clients and is not transmitted as part of the COSE message.  This means that the datagram that includes the COSE message object would be smaller by a couple of bytes (normally 2, one for the header identifier and one for the algorithm identifier).  

jim

Regards

//Samuel

On Fri, Feb 5, 2016 at 12:03 PM, Francesca Palombini <[email-masked] <mailto:[email-masked]> > wrote:

Hi Jim and all,

I understand you do not want to leave the door open for misinterpretation, and prefer to have a strong “default” behavior that cannot be misunderstood and would not create security issues derived by “common use” ; on the other hand I don’t understand how could the sentence “either you include the algorithm in the (protected part of the) message or in the externally supplied aad” be misunderstood. Why wouldn’t the restriction “no alg --> alg in external_aad” be enough in the COSE document, leaving the task to exactly define the external_aad to the application?

I am confused here because it looks to me as if you would rather accept discrepancies between COSE and application spec rather than mandate that “the alg must be included in the external_aad”. In my opinion the first would create more confusion than the second.  But I’m interested in hearing the opinion of the group of course.

tl;dr we (OSCOAP) agree with having this in an appendix if your prefer. Wondering why mandating alg in external_aad wouldn’t be “explicit enough”.

Francesca

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