Re: [jose] Text about applications and "alg":"none"

Also, note this text needs to appear in JWS, not JWA, since it's a general
requirement on JWS implementations.  So in addition to requiring
implementations to be unnecessarily complex, it also breaks the clean
separation between those documents.

On Wed, Sep 4, 2013 at 6:45 PM, Richard Barnes <rlb@ipv.sx> wrote:

> I think it's important to emphasize that an implementation MUST NOT allow
> a global setting.  In fact, I would argue that if "none" is in the
> acceptable algorithm list, it MUST be the only thing in the list.  Any
> other way, and you end up with downgrade.
>
> --Richard
>
>
> On Tue, Sep 3, 2013 at 6:47 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:
>
>>  Your proposed text seems overly verbose.  In particular, I believe
>> you’ll find that the text I proposed already means the same thing / modulo
>> the difference between RECOMMENDED and MUST.  If the WG wants a MUST we
>> could do that instead of RECOMMENDED.  We can discuss that on tomorrow’s
>> call.****
>>
>> ** **
>>
>> The correspondence is as follows:****
>>
>> Your sentence 1 is covered in my sentence 1.****
>>
>> Your sentence 2 is covered in my sentence 1.****
>>
>> Your sentence 3 is covered in my sentences 1 & 2.  In particular, the
>> “per-object basis” is already covered by “in a JWS object”.  (If it were
>> not on a per-object basis, it would have said something like “in all JWS
>> objects”.****
>>
>> ** **
>>
>>                                                                 Cheers,**
>> **
>>
>>                                                                 -- Mike**
>> **
>>
>> ** **
>>
>> *From:* Richard Barnes [mailto:rlb@ipv.sx]
>> *Sent:* Tuesday, September 03, 2013 1:33 PM
>> *To:* Mike Jones
>> *Cc:* jose@ietf.org
>> *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 <Michael.Jones@microsoft.com>
>> 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
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>> ** **
>>
>
>