Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E8C1A010F; Thu, 11 Sep 2014 13:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBFQOx5z0qJQ; Thu, 11 Sep 2014 13:29:59 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A00D1A0054; Thu, 11 Sep 2014 13:29:58 -0700 (PDT) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 818F02CA06; Thu, 11 Sep 2014 13:29:57 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Scott Kelly'" , , , References: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> Date: Thu, 11 Sep 2014 13:27:33 -0700 Message-ID: <025e01cfcdfe$d2b3f4f0$781bded0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025F_01CFCDC4.265B1060" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF5vuWrAfXHovFlfTmsz9vU+FyzJQI1m+fjnJbPWAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9vZR1f3w7bDQupuUMynZo_hy83c X-Mailman-Approved-At: Thu, 11 Sep 2014 16:56:47 -0700 Cc: jose@ietf.org Subject: Re: [secdir] [jose] secdir review of draft-ietf-jose-json-web-encryption-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 20:30:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_025F_01CFCDC4.265B1060 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, September 05, 2014 4:13 PM To: Scott Kelly; secdir@ietf.org; draft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org Cc: jose@ietf.org 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:scott@hyperthought.com] Sent: Saturday, August 30, 2014 6:13 AM To: secdir@ietf.org; draft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org 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. [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? 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? [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 ------=_NextPart_000_025F_01CFCDC4.265B1060 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

 

 

From:= = jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Friday, September 05, 2014 4:13 PM
To: = Scott Kelly; secdir@ietf.org; = draft-ietf-jose-json-web-encryption.all@tools.ietf.org; = iesg@ietf.org
Cc: jose@ietf.org
Subject: Re: [jose] = secdir review of = draft-ietf-jose-json-web-encryption-31

<= p class=3DMsoNormal> 

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:scott@hyperthought.com]=
Sent: Saturday, August 30, 2014 6:13 AM
To: secdir@ietf.org; dr= aft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org
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.

 

[JLS] Does this need = to be understood in order to implement the content covered in the core = of the document?=9A I would question that needing to understand the = entire XML Encryption document is necessary.=9A If the material is core = then it might be a better candidate for copy and paste in any event.=9A = 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?

 

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

 

[JLS] There was a = definition in the W3C document, but it appears to have disappeared.=9A = 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.=9A If it is of sufficient importance to warrant this type of = language it should be in the core document not in a considerations = section.=9A 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.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Thanks again, = Scott,

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       -- Mike

 

------=_NextPart_000_025F_01CFCDC4.265B1060--