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

From: "Richard Barnes" <[email-masked]>
Date: Wed, 01 Oct 2014 19:36:17 -0700

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

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

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.

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.

Section 6.3.2.6.
This section defines the wrong parameter.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection,
please :)

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 implementors, 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.)

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

Section 3.4.
It might be worth noting that though this format seems ad-hoc, it is the
same used by WebCrypto.

Section 4.7.1.1.
Shouldn't you require that this field MUST encode a 16-octet / 128-bit
value?

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 1 Oct 2014 20:52:01 -0700

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, October 01, 2014 7:36 PM
To: The IESG
Cc: [email-masked];
[email-masked]; [email-masked]
Subject: [jose] Richard Barnes' Discuss on
draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

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

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

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

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.

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.

Section 6.3.2.6.

Section 1.1.

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 implementors, 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.)

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

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

Section 3.4.

Section 4.7.1.1.

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Thu, 2 Oct 2014 00:07:45 -0400

On Wed, Oct 1, 2014 at 11:52 PM, Jim Schaad <[email-masked]> wrote:

> value
> dangerous
> the

Ah, OK.  Thanks for the updated reference.  I stand corrected.

--Richard

---

From: Mike Jones <[email-masked]>
Date: Mon, 6 Oct 2014 07:54:18 +0000

Thanks for your review, Richard.  Replies are inline below...

> Cc: [email-masked]; draft-ietf-jose-json-web-
> [email-masked]; [email-masked]
> Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-
> 33: (with DISCUSS and COMMENT)
> 
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 

OK

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

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

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

> This section defines the wrong parameter.

Thanks!

> The pointer for BASE64URL should be to JWS.  One level of indirection, please :)

Agreed

> registries should be removed.  They are unnecessary for interoperability, and
> highly likely to be ignored by implementors, both because (1) many
> 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).

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

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

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

				Thanks again,
				-- Mike

---

From: Richard Barnes <[email-masked]>
Date: Fri, 10 Oct 2014 17:58:08 -0400

On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones <[email-masked]>
wrote:

> email
> as part
> 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.

> without extensive
> 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?

> > This section defines the wrong parameter.

Cool.  I'll clear these points when the updated draft is posted.

> libraries
> surprised at this
> same
> 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.

> 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

---

From: Mike Jones <[email-masked]>
Date: Sat, 11 Oct 2014 20:23:05 +0000

> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Friday, October 10, 2014 2:58 PM
> To: Mike Jones
> Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
> 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-masked]> wrote:
> > 1. An implementation SHOULD NOT support "none" unless the implementer
> 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.

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

> > highly likely to be ignored by implementers, both because (1) many
> 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?

				-- Mike

---

From: Brian Campbell <[email-masked]>
Date: Mon, 13 Oct 2014 05:17:42 -0600

Something to de-emphasize RSAES-PKCS1-v1_5 seems like a good idea.

Working in the Java world, OAEP is readily available but I can't really
comment on its deployment beyond that.

On Sat, Oct 11, 2014 at 2:23 PM, Mike Jones <[email-masked]>
wrote:

> > Cc: The IESG; [email-masked];
> > Subject: Re: [jose] Richard Barnes' Discuss on
> > 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?
>

---

From: Richard Barnes <[email-masked]>
Date: Sat, 18 Oct 2014 11:18:24 -0700

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

> > > Please refer to
> http://www.ietf.org/iesg/statement/discuss-criteria.html
> 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.

I can live with this.

--Richard

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

---

From: Mike Jones <[email-masked]>
Date: Sat, 18 Oct 2014 23:09:17 +0000

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

I'm OK moving up the three sentences that actually do contain normative requirements.  Those are:

   Implementations that support Unsecured JWS objects MUST NOT accept
   such objects as valid unless the application specifies that it is
   acceptable for a specific object to not be integrity-protected.
   Implementations MUST NOT accept Unsecured JWS objects by default.
   In order to mitigate downgrade attacks, applications MUST NOT signal
   acceptance of Unsecured JWS objects at a global level, and SHOULD
   signal acceptance on a per-object basis.

I'm not OK cluttering up the normative description of the algorithm with the discussion text.  Assuming you're OK leaving the discussion text and "for example" text in 8.5, I think we have a way forward on this one.  Please let me know if that works for you. 

				-- Mike

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Oct 2014 11:48:59 -0400

On Sat, Oct 18, 2014 at 7:09 PM, Mike Jones <[email-masked]>
wrote:

> > > 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.
> >
> > 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.
>
> I'm not OK cluttering up the normative description of the algorithm with
> the discussion text.  Assuming you're OK leaving the discussion text and
> "for example" text in 8.5, I think we have a way forward on this one.
> Please let me know if that works for you.
>

Sounds fine to me.  Thanks for the compromise.

--Richard