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 1AE6A1A6FCF; Thu, 25 Sep 2014 06:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 IAWiEXwLTjZZ; Thu, 25 Sep 2014 06:17:30 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DD11A00F2; Thu, 25 Sep 2014 06:17:29 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so10748913lbg.4 for ; Thu, 25 Sep 2014 06:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fSeCWwgTLtd47Vmu1jUu/UfIi4twAp6u6gobRUilHyc=; b=0WvXY21xd4M0fFHxQNHmeY8GmGqKCpe/AVC8VTvbBy0/z57SYKCpBtGSNWku7r5yC+ /SYgZ1+SMPij5RexCy34NhH5tUvjOIttdzuRKUBKrKcEnvgNsOGmzNzGhXHus0Eb8afk bXgxL8kaEHoDatRFo/5dLJgY7oH+tk3ZP0gd3uNGIlCRLEq1zdUgqjoDe6g9+5ankyb7 QosUGab8A/4cRvQRbDpsqzhbISggcSHu4IHlKmXriYSIz/vcoNnJE0G0YOpyeHzDsSEr JN5fdYxDJI0gT8Y5F5rKvUvzt9UoFKxb+fdOAI5fcEuk+8qeyaEctokNb3faD7bIJvh7 dCHg== MIME-Version: 1.0 X-Received: by 10.152.87.193 with SMTP id ba1mr13424454lab.83.1411651047507; Thu, 25 Sep 2014 06:17:27 -0700 (PDT) Received: by 10.112.41.233 with HTTP; Thu, 25 Sep 2014 06:17:27 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BA6EFF7@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> <88AAAE10-880A-410A-A582-245FBB07E592@hyperthought.com> <4E1F6AAD24975D4BA5B16804296739439BA6EFF7@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Thu, 25 Sep 2014 09:17:27 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c345c23bcd100503e39f83 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vNBGZRHeweLFNXmoRBAt_iCc4P4 Cc: "secdir@ietf.org" , "draft-ietf-jose-json-web-encryption.all@tools.ietf.org" , "jose@ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] 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, 25 Sep 2014 13:17:38 -0000 --001a11c345c23bcd100503e39f83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote: > Thanks again for your review, Scott. The resolutions discussed below hav= e > 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:scott@hyperthought.com] > Sent: Sunday, September 07, 2014 6:35 AM > To: Mike Jones > Cc: secdir@ietf.org; > draft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org; > jose@ietf.org > Subject: Re: secdir review of draft-ietf-jose-json-web-encryption-31 > > Hi Mike, > > Responses inline below=E2=80=A6 > > On Sep 5, 2014, at 4:13 PM, Mike Jones > wrote: > > > Thanks for the useful review, Scott. I=E2=80=99ve cc=E2=80=99ed the wo= rking group in my > reply so that they=E2=80=99re aware of the contents of your review. Jim = Schaad =E2=80=93 > also please see questions to you below. Replies are inline below=E2=80= =A6 > > > > -----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 are= a > directors. Document editors and WG chairs should treat these comments ju= st > 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 scop= e, > 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 =E2=80=9CThe entire list of security > considerations is beyond the scope of this document, but some significant > considerations are listed here=E2=80=9D since several reviewers have take= n > exception to it. > > > > I=E2=80=99m 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 =E2=80=9Cthe JWS specification=E2=80= =9D rather than > [JWS]. This is a nit, not sure its important so long as you do already ha= ve > the reference. > > > > > Jim Schaad, etc., do you agree that the XMLENC reference should become > normative? I=E2=80=99d though that earlier you=E2=80=99d 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 speci= fy > documents that must be read to understand or implement the technology > in the new RFC, or whose technology must be present for the technolog= y > 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 i= n > 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=E2=80=99s comments on the Secur= ity > 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..." withou= t > ever defining M. One might guess it stands for Message, but this should b= e > 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 t= o > effectively use it. JWS requires combined confidentiality and integrity > protection, and also requires server identity verification per RFC6125, b= ut > does not mention channel binding. > > > > Scott, is there text on the channel binding problem in another > specification that you=E2=80=99d 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=E2=80=99t say channel bindings are = definitely > a problem here, only that I=E2=80=99m 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. An= y > ADs reading all the drafts will have information/context I lack, so the > comment was intended as a heads up. > > > > > 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 =E2=80=9Cmatching strengths=E2=80=9D guidance came from Eric Rescor= la and I believe > was supported by then-Security AD Sean Turner. It=E2=80=99s not clear to= me that > the =E2=89=A5 language is better than what=E2=80=99s there now, in part b= ecause if the > strengths don=E2=80=99t match, it=E2=80=99s 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 securit= y > 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.=E2=80=9D > > > 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 =E2=80=9Ckey tainting=E2=80=9D= . 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=E2=80=99d suggested that we use 2119 keywords in th= e 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 i= n > any event, the fact that JWEs can be replayed should be mentioned. > > > > It=E2=80=99s not clear to me that being able to decrypt an encrypted ob= ject > multiple times if you hold the correct key constitutes an attack, any mor= e > 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 usi= ng > JWE encryption may choose to incorporate replay protection mechanisms, su= ch > 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=E2=80= =99d 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=E2=80=99s 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 documen= t > and where they span documents, they are described in one and referenced i= n > 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= =E2=80=99t > 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. > > =E2=80=94Scott > > --=20 Best regards, Kathleen --001a11c345c23bcd100503e39f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Scott,

Thanks for your review!=C2=A0= You called out a few considerations that I think could get handled through= a reference to the developing set of best practices for TLS.=C2=A0 Since i= t is just a draft right now, it would be informative and would cover other = possible concerns with TLS.=C2=A0 I think that's a better approach sinc= e these drafts use TLS and don't define it.=C2=A0 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. =C2=A0


On Tue, Sep 23, 2014 at 7:13 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks again for your review, Scott.=C2=A0 The resolutions di= scussed below have been applied in the -32 draft, except for the proposal t= o use more normative references in the Security Considerations section, whi= ch Jim Schaad disagreed with.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: Scott Kelly [mailto:scott@h= yperthought.com]
Sent: Sunday, September 07, = 2014 6:35 AM
To: Mike Jones
Cc: secdir@ietf.org; draft-ietf-jose-= json-web-encryption.all@tools.ietf.org; iesg@ietf.org; jose@ietf.org
Subject: Re: secdir review of draft-ietf-jose-json-web-encryption-31

Hi Mike,

Responses inline below=E2=80=A6

On Sep 5, 2014, at 4:13 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> Thanks for the useful review, Scott.=C2=A0 I=E2=80=99ve cc=E2=80=99ed = the working group in my reply so that they=E2=80=99re aware of the contents= of your review.=C2=A0 Jim Schaad =E2=80=93 also please see questions to yo= u below.=C2=A0 Replies are inline below=E2=80=A6
>
> -----Original Message-----
> From: Scott Kelly [mailto:sc= ott@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.= =C2=A0 These comments were written primarily for the benefit of the securit= y area directors.=C2=A0 Document editors and WG chairs should treat these c= omments just like any other last call comments.
>
> From the abstract, JSON Web Encryption (JWE) represents encrypted cont= ent using JavaScript Object Notation (JSON) based data structures. A little= like CMS for web transactions.
>
> The security considerations section begins
>
>=C2=A0 =C2=A0 "All of the security issues that are pertinent to an= y cryptographic
>=C2=A0 =C2=A0 application must be addressed by JWS/JWE/JWK agents.=C2= =A0 Among these
>=C2=A0 =C2=A0 issues are protecting the user's asymmetric private a= nd symmetric
>=C2=A0 =C2=A0 secret keys, preventing various attacks, and helping avoi= d mistakes
>=C2=A0 =C2=A0 such as inadvertently encrypting a message to the wrong r= ecipient.
>=C2=A0 =C2=A0 The entire list of security considerations is beyond the = scope of
>=C2=A0 =C2=A0 this document, but some significant considerations are li= sted here."
>
>=C2=A0 =C2=A0"All the security considerations in the JWS specifica= tion also apply
>=C2=A0 =C2=A0 to this specification.=C2=A0 Likewise, all the security c= onsiderations in
>=C2=A0 =C2=A0 XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also a= pply, other
>=C2=A0 =C2=A0 than those that are XML specific."
>
> If you are going to point to the JWS specification, you should use a n= ormative reference. It's fine to point at other references to avoid re-= stating the obvious, but all security considerations *are* within scope, an= d require coverage, either directly or by reference. I haven't reviewed= the referenced W3C spec, so I'm not sure that everything has been cove= red. The JWS security considerations section only talks about crypto algs a= nd server identity verification. So, the ADs will want to pay attention her= e.
>
> We plan to remove the sentence =E2=80=9CThe entire list of security co= nsiderations is beyond the scope of this document, but some significant con= siderations are listed here=E2=80=9D since several reviewers have taken exc= eption to it.
>
> I=E2=80=99m 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 trig= gered by the fact that it says =E2=80=9Cthe JWS specification=E2=80=9D rath= er than [JWS]. This is a nit, not sure its important so long as you do alre= ady have the reference.

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

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

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

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


>
> FYI, as part of addressing Russ Housley=E2=80=99s comments on the Secu= rity Considerations section, I do expect to explicitly reference a number o= f 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...&q= uot; without ever defining M. One might guess it stands for Message, but th= is should be stated.
>
> Agreed
>
> Section 8 (TLS Requirements) points at JWS, but neither document refer= ences the channel binding problem. If you are depending on TLS to provide e= ssential and necessary security features (which, presumably, you are since = TLS is a MUST), then you should give clear guidance as to how to effectivel= y use it. JWS requires combined confidentiality and integrity protection, a= nd also requires server identity verification per RFC6125, but does not men= tion channel binding.
>
> Scott, is there text on the channel binding problem in another specifi= cation that you=E2=80=99d recommend that we reference or use?=C2=A0 If not,= would you mind supplying proposed text for us to use?

RFC5056 covers channel bindings, and RFC5929 covers channel bindings for TL= S. My comment is related to the requirement for TLS, which is described in = the JWS document. Note that I didn=E2=80=99t say channel bindings are defin= itely a problem here, only that I=E2=80=99m surprised they are not mentione= d.

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 in= tended as a heads up.

>
> Section 11.1 (Using Matching Algorithm Strengths) says
>
>=C2=A0 =C2=A0"Algorithms of matching strengths should be used toge= ther whenever
>=C2=A0 =C2=A0 possible.=C2=A0 For instance, when AES Key Wrap is used w= ith a given key
>=C2=A0 =C2=A0 size, using the same key size is recommended when AES GCM= is also
>=C2=A0 =C2=A0 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 =E2=80=9Cmatching strengths=E2=80=9D guidance came from Eric Resco= rla and I believe was supported by then-Security AD Sean Turner.=C2=A0 It= =E2=80=99s not clear to me that the =E2=89=A5 language is better than what= =E2=80=99s there now, in part because if the strengths don=E2=80=99t match,= it=E2=80=99s 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 con= siderations. Personally, I like the language in the security considerations= section of RFC5652:

=C2=A0 =C2=A0"When using key-agreement algorithms or previously distri= buted
=C2=A0 =C2=A0symmetric key-encryption keys, a key-encryption key is used to=
=C2=A0 =C2=A0encrypt the content-encryption key.=C2=A0 If the key-encryptio= n and
=C2=A0 =C2=A0content-encryption algorithms are different, the effective sec= urity
=C2=A0 =C2=A0is determined by the weaker of the two algorithms.=C2=A0 If, f= or example,
=C2=A0 =C2=A0content is encrypted with Triple-DES using a 168-bit Triple-DE= S
=C2=A0 =C2=A0content-encryption key, and the content-encryption key is wrap= ped
=C2=A0 =C2=A0with RC2 using a 40-bit RC2 key-encryption key, then at most 4= 0 bits
=C2=A0 =C2=A0of protection is provided.=C2=A0 A trivial search to determine= the value
=C2=A0 =C2=A0of the 40-bit RC2 key can recover the Triple-DES key, and then= the
=C2=A0 =C2=A0Triple-DES key can be used to decrypt the content.=C2=A0 There= fore,
=C2=A0 =C2=A0implementers must ensure that key-encryption algorithms are as= strong
=C2=A0 =C2=A0or stronger than content-encryption algorithms.=E2=80=9D

>=C2=A0 And you might want to point to RFC3766 for BCPs when using publi= c keys.
>
> The RFC 3766 reference looks like a good one.=C2=A0 Thanks for providi= ng it.
>
> Section 11.2 introduces the term "key tainting". "Stric= t key management/usage policy" might be better understood. Also, it mi= ght be valuable to use SHOULD here.
>
> Jim Schaad, you suggested using the term =E2=80=9Ckey tainting=E2=80= =9D.=C2=A0 Is there a place where this term is defined, which we could refe= rence?
>
> Also, Jim, I believe in our in-person discussions of issue #70 (Review= of 2119 Language) you=E2=80=99d suggested that we use 2119 keywords in the= Security Considerations statements.=C2=A0 Am I remembering that right, or = would you prefer that the Security Considerations sections use 2119 languag= e?
>
> I was surprised not to see any mention of the lack of replay protectio= n. 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=E2=80=99s not clear to me that being able to decrypt an encrypted o= bject 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 th= e wrapped key to the target client. This is one of the threats you may be i= ntending to mitigate with TLS, but based on my reading, that is not clear t= o me. And I think that to fully leverage TLS for this purpose, you must add= ress the channel bindings problem.

(I think you allude to this in the next paragraph of your reply, but it see= ms less confusing to insert this comment here)

> I agree with you that some higher-level objects that may use JWE (or J= WS) may want replay protection.=C2=A0 For instance,http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#sectio= n-4.1.7 describes a means of replay protection for JWTs.=C2=A0 At most,= if we mention replay protection, I would propose that we say that some app= lications using JWE encryption may choose to incorporate replay protection = mechanisms, such as by including IDs in the protected content that change w= ith each application-level usage.=C2=A0 Would that work for you Scott, or i= s there something else you had in mind?
>
> As always, if you can supply specific proposed language to address you= r concern, that would probably be the clearest statement of what you=E2=80= =99d like to see.
>
> I would suggest that the authors read the security considerations in r= fc5652; most of the same concerns apply here, and you could almost cut/past= e from there to here.
>
> Thanks.=C2=A0 I expect to reference some of these as well when address= ing Russ Housley=E2=80=99s gen-art review comments of JWS.
>
> For the ADs: I'm not sure if one of the companion documents provid= es a comprehensive threat model, but you will want to pay attention here. T= his doc does not.
>
> Each doc tries to list security considerations specific to that docume= nt and where they span documents, they are described in one and referenced = in others.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Thanks again, Scott,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0-- Mike

One more comment related to security considerations, comprehensive threat m= odel, etc.: RFC3552 gives a roadmap for security considerations. Your famil= y of documents should cover that roadmap. I understand that you don=E2=80= =99t want to repeat things in every document, but the ADs will have to ensu= re that, however you approach it, everything is covered. That was my point.=

=E2=80=94Scott




--
=

Best regards,
Kathleen
--001a11c345c23bcd100503e39f83--