Subject: [jose] Mxed Signature Algorithm TYpes

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Sep 2013 15:14:31 -0700

A side question from this discussion that I would like to see addressed is
should we state any recommendations about mixing different types of
signatures algorithms in the same message.

I would think that it makes sense to say that type types "none", "mac" and
"asymmetric-Signature" should never be mixed in the same message because
these different types of algorithms have significantly different security
properties.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Tuesday, September 03, 2013 1:33 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Text about applications and "alg":"none"

This text is still far too weak, and does not reflect what I remember EKR
saying (in particular, there is no MUST).  It does not address the attack
where an application may, in general, be willing to accept both signed and
unsigned content, but each in specific contexts.  Proposed text:

"""

JWS implementations MUST provide an interface for applications to specify a
list of "alg" values that are acceptable for the validation of a given JWS
object.  JWS implementations MUST NOT indicate that a JWS object is valid if
the "alg" value for the object is "none", unless the application has
specifically indicated that the value "none" is acceptable for the
particular JWS object being validated.  Applications using "none" MUST
indicate support on a per-object basis, in order to avoid downgrade attacks
that arise if more broadly-applicable preferences are specified.

"""

I continue to believe that this is far too subtle, and that applications are
very likely to get it wrong.  It is far simpler and safer to require that a
JWS implementation MUST reject an object with "alg":"none", and have another
content type for unsigned content.

Also, if "none" is going to remain, then it needs to be OPTIONAL.  Given all
the above limitations, I don't see how you could justify it being mandatory.

--Richard

On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones <[email-masked]>
wrote:

I took an action item during the last call to write text along the lines
suggested by ekr about applications and "alg":"none".  I propose that the
following text be included:

It is RECOMMENDED that libraries provide applications a means of specifying
the list of acceptable algorithms used in a JWS object in a way that causes
inputs using algorithms outside the specified set to be rejected.  In
particular, it is intended for applications to use this mechanism to exclude
accepting inputs using "alg":"none" in security contexts where non-integrity
protected inputs are not acceptable.

Feedback/proposed wording refinements welcomed.

                                                                -- Mike

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 4 Sep 2013 07:23:18 -0700

I would note that this is one of those cases that a required use of the typ
field makes a lot of sense.

Set typ to one of JWN, JWM or JWS

Only allow those algorithms which match the typ to be validated by the
library

Set up the convention that specs that want to impose more requirements would
use "Foo+JWS" as their type indicator so that the library still knows which
of the types to be checking against algorithms

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Schaad
Sent: Tuesday, September 03, 2013 3:15 PM
To: 'Richard Barnes'; 'Mike Jones'
Cc: [email-masked]
Subject: [jose] Mxed Signature Algorithm TYpes

 

"""

"""

--Richard

                                                                -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Wed, 4 Sep 2013 18:42:13 -0400

I'm not sure the difference is so great between MAC and (real) signature.
 If the recipient doesn't have the right MAC key(s), those signatures will
just fail.

I would certainly agree that "none" should never be mixed in.  If the
validator library is going to return an array of validation results (for
example), it has to choose "true" or "false", neither of which is
appropriate for "none".

On Tue, Sep 3, 2013 at 6:14 PM, Jim Schaad <[email-masked]> wrote:

> signatures algorithms in the same message.****
>
> ** **
>
> I would think that it makes sense to say that type types “none”, “mac” and
> “asymmetric-Signature” should never be mixed in the same message because
> properties.****
> ** **
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Tuesday, September 03, 2013 1:33 PM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Text about applications and "alg":"none"****
>
> ** **
>
> unsigned content, but each in specific contexts.  Proposed text:****
>
> ** **
>
> """****
>
> JWS implementations MUST provide an interface for applications to specify
> a list of "alg" values that are acceptable for the validation of a given
> JWS object.  JWS implementations MUST NOT indicate that a JWS object is
> valid if the "alg" value for the object is "none", unless the application
> has specifically indicated that the value "none" is acceptable for the
> that arise if more broadly-applicable preferences are specified.****
>
> """****
>
> ** **
>
> I continue to believe that this is far too subtle, and that applications
> are very likely to get it wrong.  It is far simpler and safer to require
> that a JWS implementation MUST reject an object with "alg":"none", and have
> another content type for unsigned content.****
>
> ** **
>
> Also, if "none" is going to remain, then it needs to be OPTIONAL.  Given
> all the above limitations, I don't see how you could justify it being
> mandatory.****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> wrote:****
> following text be included:****
>
>  ****
>
> It is RECOMMENDED that libraries provide applications a means of
> specifying the list of acceptable algorithms used in a JWS object in a way
> that causes inputs using algorithms outside the specified set to be
> rejected.  In particular, it is intended for applications to use this
> mechanism to exclude accepting inputs using "alg":"none" in security
> contexts where non-integrity protected inputs are not acceptable.****
>
>  ****
>
> Feedback/proposed wording refinements welcomed.****
>
>  ****
>
>                                                                 -- Mike***
> *
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 4 Sep 2013 22:44:58 +0000

I agree that there's times when both MACs and Signatures will be applied to the same content.  For instance, if I'm changing algorithms in my system from HMAC to ECDSA and want to confirm to the recipient that I am in possession of both the old MAC key and the new signing key.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, September 04, 2013 3:42 PM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: Mxed Signature Algorithm TYpes

I'm not sure the difference is so great between MAC and (real) signature.  If the recipient doesn't have the right MAC key(s), those signatures will just fail.

I would certainly agree that "none" should never be mixed in.  If the validator library is going to return an array of validation results (for example), it has to choose "true" or "false", neither of which is appropriate for "none".

On Tue, Sep 3, 2013 at 6:14 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
A side question from this discussion that I would like to see addressed is should we state any recommendations about mixing different types of signatures algorithms in the same message.

I would think that it makes sense to say that type types "none", "mac" and "asymmetric-Signature" should never be mixed in the same message because these different types of algorithms have significantly different security properties.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Tuesday, September 03, 2013 1:33 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Text about applications and "alg":"none"

This text is still far too weak, and does not reflect what I remember EKR saying (in particular, there is no MUST).  It does not address the attack where an application may, in general, be willing to accept both signed and unsigned content, but each in specific contexts.  Proposed text:

"""
JWS implementations MUST provide an interface for applications to specify a list of "alg" values that are acceptable for the validation of a given JWS object.  JWS implementations MUST NOT indicate that a JWS object is valid if the "alg" value for the object is "none", unless the application has specifically indicated that the value "none" is acceptable for the particular JWS object being validated.  Applications using "none" MUST indicate support on a per-object basis, in order to avoid downgrade attacks that arise if more broadly-applicable preferences are specified.
"""

I continue to believe that this is far too subtle, and that applications are very likely to get it wrong.  It is far simpler and safer to require that a JWS implementation MUST reject an object with "alg":"none", and have another content type for unsigned content.

Also, if "none" is going to remain, then it needs to be OPTIONAL.  Given all the above limitations, I don't see how you could justify it being mandatory.

--Richard

On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I took an action item during the last call to write text along the lines suggested by ekr about applications and "alg":"none".  I propose that the following text be included:

It is RECOMMENDED that libraries provide applications a means of specifying the list of acceptable algorithms used in a JWS object in a way that causes inputs using algorithms outside the specified set to be rejected.  In particular, it is intended for applications to use this mechanism to exclude accepting inputs using "alg":"none" in security contexts where non-integrity protected inputs are not acceptable.

                                                                -- Mike

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