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

[Richard Barnes <[e-mail]>]

On Sat, Oct 11, 2014 at 1:23 PM, Mike Jones <[e-mail]>
wrote:

> > 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.
>

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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/jose
> >
> >                                 Thanks again,
> >                                 -- Mike
>
>                                 -- Mike
>
>