On Sat, Oct 11, 2014 at 1:23 PM, Mike Jones <[email protected]> wrote:
> > From: Richard Barnes [mailto:[email protected]] > > Sent: Friday, October 10, 2014 2:58 PM > > 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 Mon, Oct 6, 2014 at 3:54 AM, Mike Jones <[email protected]> > wrote: > > Thanks for your review, Richard. Replies are inline below... > > > > > -----Original Message----- > > > From: jose [mailto:[email protected]] On Behalf Of Richard Barnes > > > Sent: Wednesday, October 01, 2014 7:36 PM > > > To: The IESG > > > Cc: [email protected]; draft-ietf-jose-json-web- > > > [email protected]; [email protected] > > > Subject: [jose] Richard Barnes' Discuss on > draft-ietf-jose-json-web-algorithms- > > > 33: (with DISCUSS and COMMENT) > > > > > > Richard Barnes has entered the following ballot position for > > > draft-ietf-jose-json-web-algorithms-33: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > email > > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > > paragraph, however.) > > > > > > > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Section 3.2. > > > "This computed HMAC value is then compared to the result of base64url > > > decoding the received encoded JWS Signature value." > > > Need to add: > > > "In order to avoid timing attacks, the comparison of the computed HMAC > value > > > to the JWS Signature value MUST be done in a constant-time manner." > > > > OK > > > > > 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. > 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. > > > > Section 4.2. > > > Systems that support RSAES-PKCS1-V1_5 key unwrap are commonly > vulnerable > > > to oracle attacks based on whether they accept the wrapped key or not. > > > See, e.g., > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431 > > > http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/ > > > In light of that, it seems irresponsible to include this algorithm > without extensive > > > security precautions, and especially irresponsible for it to be > REQUIRED. It's > > > been dropped from WebCrypto, and is being dropped from TLS in v1.3. > > > > The reasons for its inclusion and security considerations about it are > already covered in Section 8.3 of JWA (RSAES-PKCS1-v1_5 Security > Considerations). If you'd like to beef up the text there, specific > additional proposed wording would be welcomed. It's required because it's > the one asymmetric key encryption algorithm that appeared to be > ubiquitously deployed across development platforms. Otherwise, there would > be no practical basis for interoperability for this functionality. > > > > Thanks for the pointer to 8.3. I had missed that. That helps, but > doesn't resolve the issue. > > My concern here is that by having RSAES-PKCS1-v1_5 as a REQUIRED > algorithm, we will encourage the creation of more vulnerable stacks, and > extend the life of those that already exist. (Note that this is > independent of the guidance in RFC 3447.) Could we compromise on moving > the requirement level for this algorithm to OPTIONAL, and promoting OAEP to > REQUIRED? > > Rather than Optional, I'd counter-propose to change it to Recommended- and > changing OAEP to Recommended+. It's not clear that OAEP is widely enough > deployed yet to make it REQUIRED. What do others in the working group > think? > I can live with this. --Richard > > > > Section 6.3.1. > > > The descriptions of these parameters are really vague, especially when > it comes > > > to the "oth" parameters. Please cite a reference that provides more > detail, e.g., > > > RFC 3447. > > > > I agree that an RFC 3447 reference would be appropriate. > > > > > Section 6.3.2.6. > > > This section defines the wrong parameter. > > > > Thanks! > > > > Cool. I'll clear these points when the updated draft is posted. > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Section 1.1. > > > The pointer for BASE64URL should be to JWS. One level of indirection, > please :) > > > > Agreed > > > > > Section 3.1, 4.1, and 5.1. > > > As I said in the working group, the implementation requirements in > these > > > registries should be removed. They are unnecessary for > interoperability, and > > > highly likely to be ignored by implementers, both because (1) many > > > implementations are for specific applications that do not require all > of the > > > REQUIRED algorithms, and (2) many implementations use cryptographic > libraries > > > that do not support some REQUIRED algorithms. I have personally > written more > > > than one JWS/JWE implementation that ignored these requirements, for > exactly > > > these reasons. (This would be a DISCUSS for me, if not for my having > made this > > > argument already in the WG.) > > > > For what it's worth, apparently Stephen Farrell disagrees with you (as > do many in the working group). > > > Section 3.2. > > > "A key of the same size as the hash output (for instance, 256 bits for > > > "HS256") or larger MUST be used with this algorithm." > > > A pointer to Section 3 of RFC 2104 here would be helpful. I was > surprised at this > > > requirement, given that FIPS 198 says "The size of the key, K, shall > be equal to or > > > greater than L/2, where L is the size of the hash function output." > > > > The thread with Jim Schaad on this topic concluded as follows: > > > > [JLS] This does not seem to be the statement in sp800-107 rev1 (section > > 5.3.4) which updated FIPS 198. It says that the security = min (length > of > > K, 2*C) where C is the internal barrel length. > > > > Ah, OK. Thanks for the updated reference. I stand corrected. > > --Richard > > > > > Section 3.4. > > > It might be worth noting that though this format seems ad-hoc, it is > the same > > > used by WebCrypto. > > > > I'll think about if there's a non-intrusive way to add this. Are there > other places also using this representation? I'd thought that there were. > > > > I was going to say that this is how some libraries do it, but > unfortunately, that doesn't appear to be true of either of the libraries I > checked, NSS and OpenSSL. NSS uses a DER form, and OpenSSL uses a struct > with two integers. > > OK - then it's not clear that there's anything else definitive to say, > unless we want to add a note that this is the same representation used by > WebCrypto. Do you think that's worth adding? > > > > Section 4.7.1.1. > > > Shouldn't you require that this field MUST encode a 16-octet / 128-bit > value? > > > > Actually, 4.7 already states "Use of an Initialization Vector of size 96 > bits is REQUIRED with this algorithm." (See the GCM spec for why.) But I > could add "96 bit" to the description. > > > > Good catch. Seems like the extra mention wouldn't hurt. > > --Richard > > > > > > > _______________________________________________ > > > jose mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/jose > > > > Thanks again, > > -- Mike > > -- Mike > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
