Subject: Re: [secdir] secdir review of draft-ietf-jose-json-web-encryption-31

From: Mike Jones <[email-masked]>
Date: Fri, 5 Sep 2014 23:13:05 +0000

Thanks for the useful review, Scott.  I've cc'ed the working group in my reply so that they're aware of the contents of your review.  Jim Schaad - also please see questions to you below.  Replies are inline below...

-----Original Message-----
From: Scott Kelly [mailto:[email-masked]]
Sent: Saturday, August 30, 2014 6:13 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: secdir review of draft-ietf-jose-json-web-encryption-31

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

>From the abstract, JSON Web Encryption (JWE) represents encrypted content using JavaScript Object Notation (JSON) based data structures. A little like CMS for web transactions.

The security considerations section begins

   "All of the security issues that are pertinent to any cryptographic

   application must be addressed by JWS/JWE/JWK agents.  Among these

   issues are protecting the user's asymmetric private and symmetric

   secret keys, preventing various attacks, and helping avoid mistakes

   such as inadvertently encrypting a message to the wrong recipient.

   The entire list of security considerations is beyond the scope of

   this document, but some significant considerations are listed here."

  "All the security considerations in the JWS specification also apply

   to this specification.  Likewise, all the security considerations in

   XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other

   than those that are XML specific."

If you are going to point to the JWS specification, you should use a normative reference. It's fine to point at other references to avoid re-stating the obvious, but all security considerations *are* within scope, and require coverage, either directly or by reference. I haven't reviewed the referenced W3C spec, so I'm not sure that everything has been covered. The JWS security considerations section only talks about crypto algs and server identity verification. So, the ADs will want to pay attention here.

We plan to remove the sentence "The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here" since several reviewers have taken exception to it.

I'm a bit confused by your comment about normative references, because the JWS reference already is normative.

Jim Schaad, etc., do you agree that the XMLENC reference should become normative?  I'd though that earlier you'd advised me that security considerations references should be informative.

FYI, as part of addressing Russ Housley's comments on the Security Considerations section, I do expect to explicitly reference a number of security considerations called out in XMLENC, such as the text on chosen-ciphertext attacks, backwards compatibility attacks, etc.

In section 5.1 (Message Encryption), step 16 says "Encrypt M..." without ever defining M. One might guess it stands for Message, but this should be stated.

Agreed

Section 8 (TLS Requirements) points at JWS, but neither document references the channel binding problem. If you are depending on TLS to provide essential and necessary security features (which, presumably, you are since TLS is a MUST), then you should give clear guidance as to how to effectively use it. JWS requires combined confidentiality and integrity protection, and also requires server identity verification per RFC6125, but does not mention channel binding.

Scott, is there text on the channel binding problem in another specification that you'd recommend that we reference or use?  If not, would you mind supplying proposed text for us to use?

Section 11.1 (Using Matching Algorithm Strengths) says

  "Algorithms of matching strengths should be used together whenever

   possible.  For instance, when AES Key Wrap is used with a given key

   size, using the same key size is recommended when AES GCM is also

   used."

This doesn't quite scan for me, but editorial nits aside, it might be good to say greater or equal key sizes should be used for wrapping.

The "matching strengths" guidance came from Eric Rescorla and I believe was supported by then-Security AD Sean Turner.  It's not clear to me that the ≥ language is better than what's there now, in part because if the strengths don't match, it's not clear to me which way the inequality should go.

And you might want to point to RFC3766 for BCPs when using public keys.

The RFC 3766 reference looks like a good one.  Thanks for providing it.

Section 11.2 introduces the term "key tainting". "Strict key management/usage policy" might be better understood. Also, it might be valuable to use SHOULD here.

Jim Schaad, you suggested using the term "key tainting".  Is there a place where this term is defined, which we could reference?

Also, Jim, I believe in our in-person discussions of issue #70 (Review of 2119 Language) you'd suggested that we use 2119 keywords in the Security Considerations statements.  Am I remembering that right, or would you prefer that the Security Considerations sections use 2119 language?

I was surprised not to see any mention of the lack of replay protection. TLS channel binding could presumably be leveraged for this purpose, but in any event, the fact that JWEs can be replayed should be mentioned.

It's not clear to me that being able to decrypt an encrypted object multiple times if you hold the correct key constitutes an attack, any more than being able to check a signature multiple times does.

I agree with you that some higher-level objects that may use JWE (or JWS) may want replay protection.  For instance, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#section-4.1.7 describes a means of replay protection for JWTs.  At most, if we mention replay protection, I would propose that we say that some applications using JWE encryption may choose to incorporate replay protection mechanisms, such as by including IDs in the protected content that change with each application-level usage.  Would that work for you Scott, or is there something else you had in mind?

As always, if you can supply specific proposed language to address your concern, that would probably be the clearest statement of what you'd like to see.

I would suggest that the authors read the security considerations in rfc5652; most of the same concerns apply here, and you could almost cut/paste from there to here.

Thanks.  I expect to reference some of these as well when addressing Russ Housley's gen-art review comments of JWS.

For the ADs: I'm not sure if one of the companion documents provides a comprehensive threat model, but you will want to pay attention here. This doc does not.

Each doc tries to list security considerations specific to that document and where they span documents, they are described in one and referenced in others.

                                                                Thanks again, Scott,

                                                                -- Mike

---

From: Scott Kelly <[email-masked]>
Date: Sun, 7 Sep 2014 06:34:30 -0700

Hi Mike,

Responses inline below…

On Sep 5, 2014, at 4:13 PM, Mike Jones <[email-masked]> wrote:

> Thanks for the useful review, Scott.  I’ve cc’ed the working group in my reply so that they’re aware of the contents of your review.  Jim Schaad – also please see questions to you below.  Replies are inline below…
>  
> We plan to remove the sentence “The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here” since several reviewers have taken exception to it.
>  
> I’m a bit confused by your comment about normative references, because the JWS reference already is normative.

I started by reading the security considerations, and that comment was triggered by the fact that it says “the JWS specification” rather than [JWS]. This is a nit, not sure its important so long as you do already have the reference.

>  
> Jim Schaad, etc., do you agree that the XMLENC reference should become normative?  I’d though that earlier you’d advised me that security considerations references should be informative.

See https://www.ietf.org/iesg/statement/normative-informative.html, where it says

   "Within an RFC, references to other documents fall into two general 
    categories: "normative" and "informative". Normative references specify
    documents that must be read to understand or implement the technology 
    in the new RFC, or whose technology must be present for the technology
    in the new RFC to work. An informative reference is not normative; 
    rather, it only provides additional information. For example, an 
    informative reference might provide background or historical information.
    Informative references are not required to implement the technology in 
    the RFC."

If what is being described are security *requirements*, then I think the reference should be normative.

>  
> FYI, as part of addressing Russ Housley’s comments on the Security Considerations section, I do expect to explicitly reference a number of security considerations called out in XMLENC, such as the text on chosen-ciphertext attacks, backwards compatibility attacks, etc.
>  
> Scott, is there text on the channel binding problem in another specification that you’d recommend that we reference or use?  If not, would you mind supplying proposed text for us to use?

RFC5056 covers channel bindings, and RFC5929 covers channel bindings for TLS. My comment is related to the requirement for TLS, which is described in the JWS document. Note that I didn’t say channel bindings are definitely a problem here, only that I’m surprised they are not mentioned.

Whether or not channel bindings need to be addressed depends on the threats you intend to address. Some of my other comments were intended to indicate that the scope of threats/protections are not explicit in this draft, and after a quick scan of JWS, they still were not clear to me. Any ADs reading all the drafts will have information/context I lack, so the comment was intended as a heads up.

> The “matching strengths” guidance came from Eric Rescorla and I believe was supported by then-Security AD Sean Turner.  It’s not clear to me that the ≥ language is better than what’s there now, in part because if the strengths don’t match, it’s not clear to me which way the inequality should go.

Ruling out the use of stronger keys for wrapping seems non-intuitive to me, but your point illustrates that this may introduce additional security considerations. Personally, I like the language in the security considerations section of RFC5652:

   "When using key-agreement algorithms or previously distributed
   symmetric key-encryption keys, a key-encryption key is used to
   encrypt the content-encryption key.  If the key-encryption and
   content-encryption algorithms are different, the effective security
   is determined by the weaker of the two algorithms.  If, for example,
   content is encrypted with Triple-DES using a 168-bit Triple-DES
   content-encryption key, and the content-encryption key is wrapped
   with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits
   of protection is provided.  A trivial search to determine the value
   of the 40-bit RC2 key can recover the Triple-DES key, and then the
   Triple-DES key can be used to decrypt the content.  Therefore,
   implementers must ensure that key-encryption algorithms are as strong
   or stronger than content-encryption algorithms.”

> Jim Schaad, you suggested using the term “key tainting”.  Is there a place where this term is defined, which we could reference?
>  
> Also, Jim, I believe in our in-person discussions of issue #70 (Review of 2119 Language) you’d suggested that we use 2119 keywords in the Security Considerations statements.  Am I remembering that right, or would you prefer that the Security Considerations sections use 2119 language?
>  
> It’s not clear to me that being able to decrypt an encrypted object multiple times if you hold the correct key constitutes an attack, any more than being able to check a signature multiple times does.

One example: once a symmetric key is compromised (wrapping or wrapped key), the bad actor who holds that key can impersonate the server and provide the wrapped key to the target client. This is one of the threats you may be intending to mitigate with TLS, but based on my reading, that is not clear to me. And I think that to fully leverage TLS for this purpose, you must address the channel bindings problem.
 
(I think you allude to this in the next paragraph of your reply, but it seems less confusing to insert this comment here)

> I agree with you that some higher-level objects that may use JWE (or JWS) may want replay protection.  For instance,http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#section-4.1.7 describes a means of replay protection for JWTs.  At most, if we mention replay protection, I would propose that we say that some applications using JWE encryption may choose to incorporate replay protection mechanisms, such as by including IDs in the protected content that change with each application-level usage.  Would that work for you Scott, or is there something else you had in mind?
>  
> As always, if you can supply specific proposed language to address your concern, that would probably be the clearest statement of what you’d like to see.
>  
> Thanks.  I expect to reference some of these as well when addressing Russ Housley’s gen-art review comments of JWS.
>  

One more comment related to security considerations, comprehensive threat model, etc.: RFC3552 gives a roadmap for security considerations. Your family of documents should cover that roadmap. I understand that you don’t want to repeat things in every document, but the ADs will have to ensure that, however you approach it, everything is covered. That was my point.

—Scott

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 11 Sep 2014 13:27:33 -0700

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, September 05, 2014 4:13 PM
To: Scott Kelly; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [jose] secdir review of draft-ietf-jose-json-web-encryption-31

Thanks for the useful review, Scott.  I've cc'ed the working group in my
reply so that they're aware of the contents of your review.  Jim Schaad -
also please see questions to you below.  Replies are inline below:

-----Original Message-----
From: Scott Kelly [mailto:[email-masked]] 
Sent: Saturday, August 30, 2014 6:13 AM
To: [email-masked]; [email-masked];
[email-masked]

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

>From the abstract, JSON Web Encryption (JWE) represents encrypted content
using JavaScript Object Notation (JSON) based data structures. A little like
CMS for web transactions.

If you are going to point to the JWS specification, you should use a
normative reference. It's fine to point at other references to avoid
re-stating the obvious, but all security considerations *are* within scope,
and require coverage, either directly or by reference. I haven't reviewed
the referenced W3C spec, so I'm not sure that everything has been covered.
The JWS security considerations section only talks about crypto algs and
server identity verification. So, the ADs will want to pay attention here.

We plan to remove the sentence "The entire list of security considerations
is beyond the scope of this document, but some significant considerations
are listed here" since several reviewers have taken exception to it.

I'm a bit confused by your comment about normative references, because the
JWS reference already is normative.

Jim Schaad, etc., do you agree that the XMLENC reference should become
normative?  I'd though that earlier you'd advised me that security
considerations references should be informative.

[JLS] Does this need to be understood in order to implement the content
covered in the core of the document?  I would question that needing to
understand the entire XML Encryption document is necessary.  If the material
is core then it might be a better candidate for copy and paste in any event.
This is esp. true given that the material is qualified as - anything that is
not XML and the exercise of making that determination is left up to the
reader.

FYI, as part of addressing Russ Housley's comments on the Security
Considerations section, I do expect to explicitly reference a number of
security considerations called out in XMLENC, such as the text on
chosen-ciphertext attacks, backwards compatibility attacks, etc.

In section 5.1 (Message Encryption), step 16 says "Encrypt M..." without
ever defining M. One might guess it stands for Message, but this should be
stated. 

Agreed

Section 8 (TLS Requirements) points at JWS, but neither document references
the channel binding problem. If you are depending on TLS to provide
essential and necessary security features (which, presumably, you are since
TLS is a MUST), then you should give clear guidance as to how to effectively
use it. JWS requires combined confidentiality and integrity protection, and
also requires server identity verification per RFC6125, but does not mention
channel binding.

Scott, is there text on the channel binding problem in another specification
that you'd recommend that we reference or use?  If not, would you mind
supplying proposed text for us to use?

   used."

This doesn't quite scan for me, but editorial nits aside, it might be good
to say greater or equal key sizes should be used for wrapping.

The "matching strengths" guidance came from Eric Rescorla and I believe was
supported by then-Security AD Sean Turner.  It's not clear to me that the ?
language is better than what's there now, in part because if the strengths
don't match, it's not clear to me which way the inequality should go.

Section 11.2 introduces the term "key tainting". "Strict key
management/usage policy" might be better understood. Also, it might be
valuable to use SHOULD here.

Jim Schaad, you suggested using the term "key tainting".  Is there a place
where this term is defined, which we could reference?

[JLS] There was a definition in the W3C document, but it appears to have
disappeared.  The text they had was

"Such mitigations may include restricting a generic key ("tainting") 

> once it has been used with a specific algorithm or operation, and only 

> permit applications to use that key with that same algorithm or 

> operation in the future."

Also, Jim, I believe in our in-person discussions of issue #70 (Review of
2119 Language) you'd suggested that we use 2119 keywords in the Security
Considerations statements.  Am I remembering that right, or would you prefer
that the Security Considerations sections use 2119 language?

I am generically opposed to the use of 2119 language in security
considerations and appendixes.  If it is of sufficient importance to warrant
this type of language it should be in the core document not in a
considerations section.  However I am not in the majority on this position.

I was surprised not to see any mention of the lack of replay protection. TLS
channel binding could presumably be leveraged for this purpose, but in any
event, the fact that JWEs can be replayed should be mentioned.

It's not clear to me that being able to decrypt an encrypted object multiple
times if you hold the correct key constitutes an attack, any more than being
able to check a signature multiple times does.

I agree with you that some higher-level objects that may use JWE (or JWS)
may want replay protection.  For instance,
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#section-4.1.7
describes a means of replay protection for JWTs.  At most, if we mention
replay protection, I would propose that we say that some applications using
JWE encryption may choose to incorporate replay protection mechanisms, such
as by including IDs in the protected content that change with each
application-level usage.  Would that work for you Scott, or is there
something else you had in mind?

As always, if you can supply specific proposed language to address your
concern, that would probably be the clearest statement of what you'd like to
see.

I would suggest that the authors read the security considerations in
rfc5652; most of the same concerns apply here, and you could almost
cut/paste from there to here.

Thanks.  I expect to reference some of these as well when addressing Russ
Housley's gen-art review comments of JWS.

For the ADs: I'm not sure if one of the companion documents provides a
comprehensive threat model, but you will want to pay attention here. This
doc does not.

Each doc tries to list security considerations specific to that document and
where they span documents, they are described in one and referenced in
others.

                                                                Thanks
again, Scott,

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Sep 2014 23:13:25 +0000

Thanks again for your review, Scott.  The resolutions discussed below have been applied in the -32 draft, except for the proposal to use more normative references in the Security Considerations section, which Jim Schaad disagreed with.

				-- Mike

-----Original Message-----
From: Scott Kelly [mailto:[email-masked]] 
Sent: Sunday, September 07, 2014 6:35 AM
To: Mike Jones
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-jose-json-web-encryption-31

Hi Mike,

Responses inline below…

 

—Scott

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 25 Sep 2014 09:17:27 -0400

Hi Scott,

Thanks for your review!  You called out a few considerations that I think
could get handled through a reference to the developing set of best
practices for TLS.  Since it is just a draft right now, it would be
informative and would cover other possible concerns with TLS.  I think
that's a better approach since these drafts use TLS and don't define it.
It'll have to be informative for now and in the JWS draft since the others
point to that one for TLS guidance and won't get added until the next
revision after the IESG telechat.

https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-03

On Tue, Sep 23, 2014 at 7:13 PM, Mike Jones <[email-masked]>
wrote:

> Thanks again for your review, Scott.  The resolutions discussed below have
> been applied in the -32 draft, except for the proposal to use more
> normative references in the Security Considerations section, which Jim
> Schaad disagreed with.
>
>                                 -- Mike
>
> Cc: [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> > Thanks for the useful review, Scott.  I’ve cc’ed the working group in my
> reply so that they’re aware of the contents of your review.  Jim Schaad –
> also please see questions to you below.  Replies are inline below…
> >
> > To: [email-masked];
> > I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> > From the abstract, JSON Web Encryption (JWE) represents encrypted
> content using JavaScript Object Notation (JSON) based data structures. A
> little like CMS for web transactions.
> >
> > We plan to remove the sentence “The entire list of security
> considerations is beyond the scope of this document, but some significant
> considerations are listed here” since several reviewers have taken
> exception to it.
> >
> I started by reading the security considerations, and that comment was
> triggered by the fact that it says “the JWS specification” rather than
> [JWS]. This is a nit, not sure its important so long as you do already have
> the reference.
>
> >
> normative?  I’d though that earlier you’d advised me that security
> > FYI, as part of addressing Russ Housley’s comments on the Security
> > Section 8 (TLS Requirements) points at JWS, but neither document
> references the channel binding problem. If you are depending on TLS to
> provide essential and necessary security features (which, presumably, you
> are since TLS is a MUST), then you should give clear guidance as to how to
> effectively use it. JWS requires combined confidentiality and integrity
> protection, and also requires server identity verification per RFC6125, but
> does not mention channel binding.
> >
> > Scott, is there text on the channel binding problem in another
> specification that you’d recommend that we reference or use?  If not, would
> you mind supplying proposed text for us to use?
>
> RFC5056 covers channel bindings, and RFC5929 covers channel bindings for
> TLS. My comment is related to the requirement for TLS, which is described
> in the JWS document. Note that I didn’t say channel bindings are definitely
> a problem here, only that I’m surprised they are not mentioned.
>
> Whether or not channel bindings need to be addressed depends on the
> threats you intend to address. Some of my other comments were intended to
> indicate that the scope of threats/protections are not explicit in this
> draft, and after a quick scan of JWS, they still were not clear to me. Any
> ADs reading all the drafts will have information/context I lack, so the
> comment was intended as a heads up.
>
> >
> > This doesn't quite scan for me, but editorial nits aside, it might be
> good to say greater or equal key sizes should be used for wrapping.
> >
> > The “matching strengths” guidance came from Eric Rescorla and I believe
> was supported by then-Security AD Sean Turner.  It’s not clear to me that
> the ≥ language is better than what’s there now, in part because if the
> strengths don’t match, it’s not clear to me which way the inequality should
> go.
>
> Ruling out the use of stronger keys for wrapping seems non-intuitive to
> me, but your point illustrates that this may introduce additional security
> considerations. Personally, I like the language in the security
> considerations section of RFC5652:
>
> > Jim Schaad, you suggested using the term “key tainting”.  Is there a
> place where this term is defined, which we could reference?
> >
> > Also, Jim, I believe in our in-person discussions of issue #70 (Review
> of 2119 Language) you’d suggested that we use 2119 keywords in the Security
> Considerations statements.  Am I remembering that right, or would you
> prefer that the Security Considerations sections use 2119 language?
> >
> > I was surprised not to see any mention of the lack of replay protection.
> TLS channel binding could presumably be leveraged for this purpose, but in
> any event, the fact that JWEs can be replayed should be mentioned.
> >
> > It’s not clear to me that being able to decrypt an encrypted object
> multiple times if you hold the correct key constitutes an attack, any more
> than being able to check a signature multiple times does.
>
> One example: once a symmetric key is compromised (wrapping or wrapped
> key), the bad actor who holds that key can impersonate the server and
> provide the wrapped key to the target client. This is one of the threats
> you may be intending to mitigate with TLS, but based on my reading, that is
> not clear to me. And I think that to fully leverage TLS for this purpose,
> you must address the channel bindings problem.
>
> (I think you allude to this in the next paragraph of your reply, but it
> seems less confusing to insert this comment here)
>
> > I agree with you that some higher-level objects that may use JWE (or
> JWS) may want replay protection.  For instance,
> concern, that would probably be the clearest statement of what you’d like
> to see.
> >
> > Thanks.  I expect to reference some of these as well when addressing
> Russ Housley’s gen-art review comments of JWS.
> >
> > Each doc tries to list security considerations specific to that document
> and where they span documents, they are described in one and referenced in
> others.
> >
> >                                                                 Thanks
> again, Scott,
> >                                                                 -- Mike
>
> One more comment related to security considerations, comprehensive threat
> model, etc.: RFC3552 gives a roadmap for security considerations. Your
> family of documents should cover that roadmap. I understand that you don’t
> want to repeat things in every document, but the ADs will have to ensure
> that, however you approach it, everything is covered. That was my point.
>
> —Scott
>
>

-- 

Best regards,
Kathleen