Sorry for the delay in my response. I'll answer in-line below. Thanks!
On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad <[email protected]> wrote: > > > > > From: jose [mailto:[email protected]] On Behalf Of Mike Jones > Sent: Thursday, April 17, 2014 10:46 AM > To: Kathleen Moriarty; [email protected] > Cc: [email protected] > Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms > > > > Thanks for taking the time to do the review, Kathleen. Responses are > inline, flagged by “Mike>”. I also pasted your follow-on note in and > responded to it as well. > > > > From: Kathleen Moriarty [mailto:[email protected]] > Sent: Thursday, April 17, 2014 7:51 AM > To: [email protected] > Cc: Mike Jones; [email protected] > Subject: AD review of draft-ietf-jose-json-web-algorithms > > > > Hello Mike & JOSE members, > > > > I am working my way through the requested reviews to progress the JOSE > drafts and can see a lot of work has been done, thank you. As I read > through the Algorithms (JWA) draft there are some changes that will need to > be made to avoid problems during the IESG review. This is a pretty big > change for the draft, but will help make the review and approval faster. > Typically, the lists of algorithms are handled through a draft update as > opposed to creating an IANA registry. A good example is a recent update of > a draft in the IPSECME working group so you can see the structure and the > precedence for this model. > > > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts > > > > Mike> So you’re suggesting that future JWA drafts might obsolete the current > one, much like draft-ietf-ipsecme-esp-ah-reqts will obsolete RFC 4835, which > obsoleted RFC 4305, etc.? If so, could work on revising the JWA draft > accordingly and send proposed changes to the working group. > > KM> I am not sure where Jim's response is, but I have been looking into this. My initial message came after some conversations with Sean. In response to your posts, I reached out to a couple of other ADs who may have had concerns and *think* we are okay as long as the registries will be used with a designated expert review to add to the registry. If a draft is required for an update, that would cause problems as opposed to a draft with no registries. Sorry for the confusion here. > > Now for other edits and questions: > > > > Section 3.6 - Can you explain why would this be included? If you are not > going to sign, I am not sure why one would use JOSE at all. > > > > Mike> This is included to enable representing content that is optionally > signed in protocols using JWS. Having this means that whether or not the > content is signed, it can use a uniform representation, which is easy to > parse. This is in production use, for instance, to enable OAuth > authorization request messages that are optionally signed. Sometimes > content need not be signed at the JWS level because it’s integrity protected > by other protocol layers – in particular, often by the use of TLS. Another > use case is where signing adds additional optional value, but where there’s > no harm in using unsigned content – for instance, while normal OAuth > requests are inline and unsigned, a registered extension enables request > parameters to be passed by reference, rather than by value; the object > referenced containing the parameters is a JWS; the JWS can optionally be > signed. The current, carefully refined treatment of “none” is the result of > substantial mailing list discussions and discussions on working group calls. > While a less parallel treatment of unsigned JWSs was proposed in > http://trac.tools.ietf.org/wg/jose/trac/ticket/36, this alternative syntax > was rejected by the working group in favor of the current approach. > > KM> I responded to Vladamir on this one and would just like to know if there is WG consensus behind the decision. Can you point me to discussions on this? > > Section 5.2 - The write up of this section seems a bit more complicated than > necessary. It seems it would have just been simpler to state that the sizes > vary as required by the algorithms and key lengths used rather than > providing the differences from one to the next. Can you simplify this? > > After looking through some of the mailing list discussions, it seems there > was already agreement to slim this and other sections down by pointing to > the draft-mcgrew-aead-aes-cbc-hmac-sha2 > > > > http://www.ietf.org/mail-archive/web/jose/current/msg02276.html > > Can I get an update as to where that stands, referencing what you can from > that draft as opposed to duplicating text? Thanks! > > Mike> Sure. The key part of the message you cited is “Once the McGrew draft > has been refactored to separate the description of the calculation steps > (which JOSE is using) from the AEAD representation steps (which JOSE is not > using), and to include test vector values that show results without > performing the AEAD representation concatenations, I agree that we'll be > able to just reference it, rather than duplicating it.” The problem is that > the refactoring was never done. The algorithm description in > draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the > ciphertext C, as described, also includes the IV value as a prefix and the > authentication tag T as a suffix, rather than treating each of those as > separate values. The test vectors do the same. Yes, David added appendix B > saying that the values could be treated as separate, but the write-up does > no favors to implementers, as both the core algorithm description and the > test vectors assume they are combined. (I personally know that working out > how to treat them as separate from David’s current draft is a tedious and > error-prone exercise, having had to do so to tease them apart for the > current JWA write-up.) David has been asked about doing the refactoring > several times by multiple parties, but he’s a busy guy, and I don’t think > it’s ever reached the top of his queue. As it is, the JWA description is > clear and semantically equivalent and implementers have shown that they can > successfully build it. Finally, we wouldn’t want to take a normative > dependency upon a draft that appears to have been largely abandoned (or at > least neglected), as doing so could indefinitely stall publication of RFC > versions of the JOSE specs. > > > > [JLS] I always considered this to be a sufficient refactoring to use the > mcgrew draft as a basis. I did not have the same type of problems with > breaking the test vectors apart that you seem to have had. > KM> OK, has anyone reached out to Dave McGrew to discuss? How can we clear this up? > > > 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. > > KM> Great, thank you! > > I think that's it for now. Although I do need to look through some more of > the previous conversations on the mailing list and in the issue tracker. > > > > I see there are some open discussions, like the one Richard raised yesterday > that need to be resolved in the document as well before we move forward with > this one. Thanks for all of your effort on this draft!! > > > > Mike> Per my note > http://www.ietf.org/mail-archive/web/jose/current/msg04061.html, I don’t > believe that that particular issue is open. It had been extensively > discussed within the working group multiple times and the issue was > explicitly closed by the chairs, leaving the status quo in place in which > there are required algorithms for interoperability reasons. > > > > I'm going to add one more question to the review as I had the same thought > as Scott & Burt in their review of JWA (and also in JWS). Why are there no > other options in addition to SHA1? The response to Scott pointed back to > early WG decisions, but I have heard this concern from others and have it > myself, so I am not sure this one is resolved. I'd like to revisit it. > > > > http://www.ietf.org/mail-archive/web/jose/current/msg04020.html > > > > Mike> If adding a new “RSA-OAEP-256” algorithm identifier for “RSAES with > Optimal Asymmetric Encryption Padding using the MGF1 mask generation > function and the SHA-256 hash function” would make a number of people more > comfortable, including you, there’s nothing wrong with doing so. However, > it’s also not clear that it would be of much short-term practical benefit > because, at least as of the implementation survey done in July 2012, many > crypto libraries don’t expose a way to get at this algorithm combination. > However, the same argument could be made about RSASSA-PSS, which we did add > identifiers for in the end. In short, I don’t think anyone in the working > group would stridently object if you asked for this additional algorithm > identifier to be added. Your call… > KM> I'd say to add it. I'll have a similar comment for the JWS draft for SHA256 support on thumbprints. > > > -- > > > > Best regards, > > Kathleen > > > > Thanks a bunch, > > -- Mike > > -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
