Hi Richard, How does the draft look now, have your discusses been adequately addressed? If not all, have some of them been resolved so we can narrow this down?
Thanks! On Sat, Oct 25, 2014 at 2:35 AM, Mike Jones <[email protected]> wrote: > 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:[email protected]] > Sent: Monday, October 20, 2014 8:49 AM > To: Mike Jones > Cc: The IESG; [email protected]; > [email protected]; [email protected] > 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 <[email protected]> > 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 > > -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
