Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

[Mike Jones <[e-mail]>]

Hi Richard,

The normative security considerations text for “alg”:“none” has been moved into the algorithm definition in the -36 draft, per our agreement below.  I also added additional text referencing RFC 3447 in Section 6.3.  Your other DISCUSSes were addressed in previous drafts, including making RSAES-PKCS1-V1_5 “Recommended-”, per our agreement.  I believe that these changes should enable you to clear your remaining DISCUSSes.

                                                            Thanks again,
                                                            -- Mike

From: Richard Barnes [mailto:[e-mail]]
Sent: Monday, October 20, 2014 8:49 AM
To: Mike Jones
Cc: The IESG; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)



On Sat, Oct 18, 2014 at 7:09 PM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:
> > > Section 3.6.
> > > I'm not going to object to "none", even though I think it's a very dangerous
> > > feature because of the risk of confusion between Secured and Unsecured JWS.
> > > But there needs to be stronger guidance:
> > > 1. An implementation SHOULD NOT support "none" unless the implementer
> > > knows that it will be used in application context s that require it.
> > > 2. If an implementation does support "none", then it MUST NOT accept it as part
> > > of generic JWS validation.  Instead, it should require the application to explicitly
> > > signal that an Unsecured JWS is expected for a given validation operation.
> >
> > As discussed in the working group, your concern about applications inappropriately allowing the use of "none" actually is an instance of a more general concern that applications not allow *any* algorithms to be used that are not appropriate in their application contexts.  This concern is already addressed in the specification at the end of Section 5.2 as follows:
> >
> > "Finally, note that it is an application decision which algorithms are acceptable in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD reject the JWS."
> >
> > Since your specific concern is already handled in a more general way, I would like to request that you withdraw this DISCUSS on that basis.  Also, you were one of the contributing authors to the security considerations on this topic in Section 8.5 of JWA (Unsecured JWS Security Considerations), so it's not clear that there's any cause for you to come back with additional wording change requests on this topic at this point.
> >
> > Thanks for reminding me about Section 8.5.  I think I would be satisfied here if the contents of Section 8.5 were just moved up to this section.  That way all of the requirements for implementing "none" will be together.
>
> Section 3.6 does end with the sentence "See Section 8.5 for security considerations associated with using this algorithm" so implementers are reminded to also pay attention to the security considerations.  If we were to do what you requested, this would be the only algorithm for which the security considerations were included in the algorithm description, rather than in the security considerations section, which would be fairly weird and non-parallel, editorially.
>
> Actually, "none" is the only algorithm for which there are additional normative requirements in the Security Considerations.  So it actually seems more sensible to move those requirements up.
> I'm really just asking for a copy/paste here, shouldn't be invasive.  But I do think the level of indirection creates security risk.

I'm OK moving up the three sentences that actually do contain normative requirements.  Those are:

   Implementations that support Unsecured JWS objects MUST NOT accept
   such objects as valid unless the application specifies that it is
   acceptable for a specific object to not be integrity-protected.
   Implementations MUST NOT accept Unsecured JWS objects by default.
   In order to mitigate downgrade attacks, applications MUST NOT signal
   acceptance of Unsecured JWS objects at a global level, and SHOULD
   signal acceptance on a per-object basis.

I'm not OK cluttering up the normative description of the algorithm with the discussion text.  Assuming you're OK leaving the discussion text and "for example" text in 8.5, I think we have a way forward on this one.  Please let me know if that works for you.

Sounds fine to me.  Thanks for the compromise.
--Richard


> Again, given that you were an author of 8.5 and seemed fine with the resolution after the extensive discussion then, I'd ask you to clear the DISCUSS on that basis and not request that it be reworked again.
                                -- Mike