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

[Mike Jones <[e-mail]>]

The resolutions proposed below have been incorporated in the -34 draft.  Hopefully you can clear your DISCUSSes on that basis.

				Thanks again,
				-- Mike

> -----Original Message-----
> From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
> Sent: Saturday, October 11, 2014 1:23 PM
> To: Richard Barnes
> Cc: [e-mail]; [e-mail]; The IESG; draft-ietf-jose-json-
> [e-mail]
> Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-
> algorithms-33: (with DISCUSS and COMMENT)
> 
> > From: Richard Barnes [mailto:[e-mail]]
> > Sent: Friday, October 10, 2014 2:58 PM
> > To: Mike Jones
> > Cc: The IESG; [e-mail];
> > [e-mail]; [e-mail]
> > 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
> <[e-mail]> wrote:
> > Thanks for your review, Richard.  Replies are inline below...
> >
> > > -----Original Message-----
> > > From: jose [mailto:[e-mail]] On Behalf Of Richard
> > > Barnes
> > > Sent: Wednesday, October 01, 2014 7:36 PM
> > > To: The IESG
> > > Cc: [e-mail]; draft-ietf-jose-json-web-
> > > [e-mail]; [e-mail]
> > > 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.
> 
> 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?
> 
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/jose
> >
> >                                 Thanks again,
> >                                 -- Mike
> 
> 				-- Mike
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose