Mike> Thanks. Responses inline… From: Kathleen Moriarty [mailto:[email protected]] Sent: Monday, June 16, 2014 2:10 PM To: Mike Jones Cc: [email protected] Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
On Fri, Jun 13, 2014 at 6:15 PM, Mike Jones <[email protected]<mailto:[email protected]>> wrote: Responses to the Security Considerations wording issue are inline below (with the text unrelated to this issue removed for brevity)… Thanks! From: Kathleen Moriarty [mailto:[email protected]<mailto:[email protected]>] Sent: Friday, June 13, 2014 2:08 PM To: Mike Jones Cc: [email protected]<mailto:[email protected]> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms On Fri, Jun 13, 2014 at 4:26 PM, Mike Jones <[email protected]<mailto:[email protected]>> wrote: I didn’t reword the introductions. I thought that your issue was that you wanted additional security considerations to be described, which has now been done. I’ll go back and re-read your comments and see if I can work out what additional changes you were requesting there. Thank you, when you go back you'll see the request was two-fold. Thanks, I think it will help the intro read better! >> Security Considerations: While it is true the content is covered in >> other places, this section could benefit from improvement before it >> goes to the SecDir review. The second sentence in the first >> paragraph >> says the >> following: >> >> Among these issues are >> protecting the user's private and symmetric keys, preventing >> various >> attacks, and helping the user avoid mistakes such as inadvertently >> encrypting a message for the wrong recipient. >> > >> It would be helpful if you could expand the text and make it more >> descriptive and applicable to this document. For example, shouldn’t >> the first section say user’s private asymmetric and symmetric keys? >> I >> assume that is what was intended with private, but it reads funny to >> me without that. The only ‘attack’ or caution mentioned in the >> document is for the application to prevent a user from selecting the >> wrong key. Please include some attacks that developers and >> implementers should be aware and cautioned on, or state that specific >> attacks and considers are detailed in the subsections to follow. >> >> Mike> OK, I can work on expanding that. There are some other attacks >> mentioned in the other drafts, such as timing attacks, which can >> probably at least be mentioned here. I’ll send draft text to the >> list >> and consult with you before doing anything to the actual drafts. >> Specific suggestions from working group participants would also be >> highly appreciated. The Security Considerations section requires updating, let me know when this has been done. Thanks! Mike> The current introduction to all the JOSE security considerations sections says: All of the security issues faced by any cryptographic application must be faced by a JWS/JWE/JWK agent. Among these issues are protecting the user's private and symmetric keys, preventing various attacks, and helping the user avoid mistakes such as inadvertently encrypting a message for the wrong recipient. The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here. (And the JWT Security Considerations introduction is the same, other than also speaking about JWTs.) Now that the -27 drafts contain beefed-up text describing specific security considerations apropos to each draft, I believe that the best way to address the other part of your two-fold comment is simply to delete the second sentence (beginning “Among these issues”). I agree with you that it doesn’t add any value at this point. Do you agree with that proposed resolution, Kathleen? I can go either way, but think adding in the word asymmetric would be good. It reads a little funny without it and I know it should be obvious that it is intended, but... we have a broad set of folks who read drafts. Mike> OK, I can change “user’s private and symmetric keys” to “user’s asymmetric private and symmetric secret keys” so that the wording is parallel. Would that work for you in the introductions? I read through the updated version in JWA and am wondering why the considerations for [JWE<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWE>], [JWK<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWK>], [JWS<http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-27#ref-JWS>], are included here? Isn't it that the other documents rely on JWA and not the reverse? Mike> There’s a balancing act caused by the fact that the specific algorithms for JWS, JWE, and JWK are in the JWA spec. Where the consideration is specific to a particular algorithm, I tried to put it in the JWA spec. Where it is broader (more about signing, encrypting, or keys than about the particular algorithm), I tried to put it in the JWS, JWE, or JWK spec. In some cases, a consideration seemed applicable to both, in which case I put it in the JWS, JWE, or JWK spec and referenced it from the JWA spec. It’s also entirely possible that I haven’t been completely consistent with the above approach, so further review of the placements is probably in order. But first, I’d like to know if you agree with the principles about where things should be located that I described in the previous paragraph, or if you’d like to see things be organized differently. After I hear back from you on that, I’ll undertake the review to see if any of the considerations should move between specs, for consistency sake. We are getting close :-) Mike> Agreed :-) Thanks, Kathleen Best regards, Kathleen Have a good weekend! -- Mike -- Best regards, Kathleen -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
