Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21261A8939; Tue, 2 Sep 2014 18:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 7QT4yWgfGOBL; Tue, 2 Sep 2014 18:39:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331FB1A8935; Tue, 2 Sep 2014 18:39:56 -0700 (PDT) Received: from BN3PR0301CA0003.namprd03.prod.outlook.com (25.160.180.141) by BL2PR03MB241.namprd03.prod.outlook.com (10.255.231.15) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 01:39:52 +0000 Received: from BN1AFFO11FD014.protection.gbl (2a01:111:f400:7c10::124) by BN3PR0301CA0003.outlook.office365.com (2a01:111:e400:4000::13) with Microsoft SMTP Server (TLS) id 15.0.1019.16 via Frontend Transport; Wed, 3 Sep 2014 01:39:52 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD014.mail.protection.outlook.com (10.58.52.74) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Wed, 3 Sep 2014 01:39:51 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.122]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Wed, 3 Sep 2014 01:39:16 +0000 From: Mike Jones To: Charlie Kaufman , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-jose-json-web-algorithms-31 Thread-Index: Ac/EILVlvaO6koWmSBq1KV+ptV1KBQC8PqQw Date: Wed, 3 Sep 2014 01:39:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AE76076@TK5EX14MBXC294.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AE76076TK5EX14MBXC294r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(377454003)(51914003)(199003)(189002)(43784003)(20776003)(64706001)(50986999)(68736004)(69596002)(77982001)(80022001)(66066001)(16236675004)(19300405004)(81156004)(81542001)(106466001)(19580395003)(83322001)(71186001)(19580405001)(76176999)(54356999)(15202345003)(99396002)(79102001)(77096002)(2501002)(84326002)(90102001)(551544002)(81342001)(2656002)(19625215002)(19617315012)(551984002)(33656002)(104016003)(26826002)(230783001)(31966008)(74502001)(74662001)(4396001)(95666004)(76482001)(86612001)(512954002)(55846006)(85306004)(86362001)(6806004)(44976005)(21056001)(84676001)(83072002)(15975445006)(87936001)(107046002)(97736001)(85852003)(92726001)(46102001)(92566001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB241; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 032334F434 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Z-M0mnp1yqQJEOvdA_xAT_OeL5U Cc: "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "iesg@ietf.org" , "jose@ietf.org" Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-algorithms-31 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 01:40:01 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AE76076TK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the useful review, Charlie. Responses and proposed resolutions = follow inline. Working group - please review. From: Charlie Kaufman [mailto:charliekaufman@outlook.com] Sent: Saturday, August 30, 2014 12:12 AM To: secdir@ietf.org Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@ietf.org Subject: Secdir review of draft-ietf-jose-json-web-algorithms-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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document sets the initial IANA registry values for the labels to be us= ed to specify choices of cryptographic algorithms in the context of the JSO= N Web Encryption, JSON Web Signature, and JSON Web Key documents (parallel = I-Ds). Some aspects of how the algorithms are used are specified here; othe= rs aspects reference other documents. The issues I found with this document (all of which are minor): Section 3.4 line 4 says Elliptic Curves are generally faster to execute (fo= r equivalent security) than RSA. While that is true for private key operati= ons (and even more dramatically so for key generation), it is generally not= true for public key operations. This is a nit in the text since these trad= e-offs are well understood. What if we were to change the phrase "with greater processing speed" to "wi= th greater processing speed for many operations"? Section 4.5 Direct Encryption: It might be too late to change existing impl= ementations, but it generally a good idea when using pre-negotiated keys to= include some key identifier in the header to remove ambiguity in the case = where there are multiple pre-negotiated keys (perhaps because they are in t= he process of being updated and they are not atomically updated on both end= s of the connection). The "kid" (Key ID) header parameter defined in the JWE spec already enables= this to be done. Section 5.1: I don't believe the pairings of AES128/HMAC-SHA256, AES192/HMA= C-SHA384, and AES256/HMAC-SHA512 are "natural" in the sense of providing eq= uivalent cryptographic strength. Without the HMAC, they would, but I believ= e HMAC-SHA256 is generally believed to have 256 bits of cryptographic stren= gth, making it suitable for pairing with any of the three AES key sizes. Th= e choices of the longer SHA2 variants are conservative, however, and so do = no harm if these pairings are already in widespread use. They are in use and are the pairings chosen by David McGrew, a just departe= d CRFG chair, and Kenny Paterson, a current CRFG chair, in draft-mcgrew-aea= d-aes-cbc-hmac-sha2. Section 5.2: Similarly, it is not appropriate to have the length of the Mes= sage Authentication Code (MAC) reflect the key length, since it does not af= fect cryptographic strength but rather the strength against on-line MAC gue= ssing attacks. For this purpose, 128 bits is generally considered adequate = for all key sizes and many implementations truncate this to 96 bits or even= 64. Again, the current specification is conservative (if slightly wasteful= of bandwidth), and so does not harm if this is already in widespread use. (Same answer as to the previous comment) Section 5.2.2.1 says "The number of octets in the input key K is the sum of= MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say somethin= g like "MUST BE the sum". The text goes on to say that the two keys must no= t overlap, but it is also important that an implementation not tolerate a g= ap between the two keys is a too large key is provided. OK Section 5.2.2.2 says the authenticated decryption operation has four inputs= ... . I believe it has a fifth: the IV. Alternately, the IV is pre-pended t= o the ciphertext (and hence implicitly included in 'E'). Agreed the IV is a fifth input. I'll make this change. Section 5.3 specifies AES/GCM in much less detail than the description of A= ES/HMAC in Section 5.2. Is this because the referenced document [NIST.800-3= 8D] includes all the needed details (like use of PKCS7 padding)? Yes Section 6.2.1.1: Because of the controversy over NSA allegedly planting bac= kdoors in the "NIST curves" listed, there is a growing demand that addition= al curves be supported. You might want to specify how additional curves can= be specified in-line and/or how to get additional curves added to the IANA= registry. Agreed. We can tweak the IANA language in this section (and possibly other= s using similar language) to be clearer on this point. Section 8.7: I believe the advice in this section is too strong. It is gene= rally considered secure to encrypt multiple data sets with the same key so = long as the IV is correctly chosen and it is also generally considered secu= re to encrypt the same data set with multiple different keys. There are man= y scenarios in which this is nearly impossible to avoid. It is important th= at when encryption multiple data sets with the same key that the IV be chos= en appropriately - which is very challenging when using GCM as noted in sec= tion 8.4. The current language was added to resolve issue #28 http://trac.tools.ietf.= org/wg/jose/trac/ticket/28 and is a result of a good bit of discussion with= Michael Peck, Jim Schaad, and others in the working group on the JOSE mail= ing list between June 2013 and August 2013, with the issue being closed by = Jim in October 2013. I recognize that of the problem here is that the security considerations ac= tually vary by algorithm and yet this subsection is trying to provide gener= al guidance. Is there a specific wording change that you'd like to propose that would we= aken the advice when it's OK to weaken it, but not in any other circumstanc= es? Section 8.8: I believe the advice in this section is too weak. It is genera= lly bad practice to derive cryptographic keys from passwords as passwords a= lmost never have adequate entropy. Where possible, it would be better to ha= ve a strong (i.e. randomly chosen) cryptographic key associated with an ent= ity and then use the password to acquire that cryptographic key. There are = a number of means for doing that, including having the strong key encrypted= with the password (or XORed with it) stored someplace the entity can acces= s it, by having a server that will return the key based on a provided passw= ord, or with a strong password authentication protocol. Deriving the key fr= om a password using PBES should be a last resort and demanding a longer pas= sword to derive a 256 bit key is only fooling yourself... you are never lik= ely to get more than 64 bits of entropy. Note that password-based encryption, as used by this specification, does em= ploy a randomly chosen content encryption key, and uses the password-based = encryption only to encrypt the CEK. Does that alleviate your concerns? If= not, could you supply specific proposed wording changes that would? --Charlie Thanks agai= n, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439AE76076TK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the useful = review, Charlie.  Responses and proposed resolutions follow inline.&nb= sp; Working group – please review.

 

From: Charlie = Kaufman [mailto:charliekaufman@outlook.com]
Sent: Saturday, August 30, 2014 12:12 AM
To: secdir@ietf.org
Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@iet= f.org
Subject: Secdir review of draft-ietf-jose-json-web-algorithms-31

 

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

 

This document sets the initial IANA registry values = for the labels to be used to specify choices of cryptographic algorithms in= the context of the JSON Web Encryption, JSON Web Signature, and JSON Web K= ey documents (parallel I-Ds). Some aspects of how the algorithms are used are specified here; others aspects = reference other documents.

 

The issues I found with this document (all of which = are minor):

 

Section 3.4 line 4 says Elliptic Curves are generall= y faster to execute (for equivalent security) than RSA. While that is true = for private key operations (and even more dramatically so for key generatio= n), it is generally not true for public key operations. This is a nit in the text since these trade-offs are well = understood.

 

What if we were to cha= nge the phrase “with greater processing spee= d” to “with greater processing speed for many operations”?

 

Section 4.5 Direct Encryption: It might be too late = to change existing implementations, but it generally a good idea when using= pre-negotiated keys to include some key identifier in the header to remove= ambiguity in the case where there are multiple pre-negotiated keys (perhaps because they are in the process = of being updated and they are not atomically updated on both ends of the co= nnection).

 

The “kid” = (Key ID) header parameter defined in the JWE spec already enables this to b= e done.

 

Section 5.1: I don't believe the pairings of AES128/= HMAC-SHA256, AES192/HMAC-SHA384, and AES256/HMAC-SHA512 are "natural&q= uot; in the sense of providing equivalent cryptographic strength. Without t= he HMAC, they would, but I believe HMAC-SHA256 is generally believed to have 256 bits of cryptographic strength, making i= t suitable for pairing with any of the three AES key sizes. The choices of = the longer SHA2 variants are conservative, however, and so do no harm if th= ese pairings are already in widespread use.

 

They are in use and ar= e the pairings chosen by David McGrew, a just departed CRFG chair, and Kenn= y Paterson, a current CRFG chair, in draft-mcgrew-aead-aes-cbc-hmac-sha2.

 

Section 5.2: Similarly, it is not appropriate to hav= e the length of the Message Authentication Code (MAC) reflect the key lengt= h, since it does not affect cryptographic strength but rather the strength = against on-line MAC guessing attacks. For this purpose, 128 bits is generally considered adequate for all key si= zes and many implementations truncate this to 96 bits or even 64. Again, th= e current specification is conservative (if slightly wasteful of bandwidth)= , and so does not harm if this is already in widespread use.

 

(Same answer as to the= previous comment)

 

Section 5.2.2.1 says "The number of octets in t= he input key K is the sum of MAC_KEY_LEN and ENC_KEY_LEN." I believe i= t would be better to say something like "MUST BE the sum". The te= xt goes on to say that the two keys must not overlap, but it is also important that an implementation not tolerate a gap between= the two keys is a too large key is provided.

 

OK

 

Section 5.2.2.2 says the authenticated decryption op= eration has four inputs... . I believe it has a fifth: the IV. Alternately,= the IV is pre-pended to the ciphertext (and hence implicitly included in '= E').

 

Agreed the IV is a fif= th input.  I’ll make this change.

 

Section 5.3 specifies AES/GCM in much less detail th= an the description of AES/HMAC in Section 5.2. Is this because the referenc= ed document [NIST.800-38D] includes all the needed details (like use of PKC= S7 padding)?

 

Yes<= /p>

 

Section 6.2.1.1: Because of the controversy over NSA= allegedly planting backdoors in the "NIST curves" listed, there = is a growing demand that additional curves be supported. You might want to = specify how additional curves can be specified in-line and/or how to get additional curves added to the IANA registry.

 

Agreed.  We can t= weak the IANA language in this section (and possibly others using similar l= anguage) to be clearer on this point.

 

Section 8.7: I believe the advice in this section is= too strong. It is generally considered secure to encrypt multiple data set= s with the same key so long as the IV is correctly chosen and it is also ge= nerally considered secure to encrypt the same data set with multiple different keys. There are many scenarios i= n which this is nearly impossible to avoid. It is important that when encry= ption multiple data sets with the same key that the IV be chosen appropriat= ely – which is very challenging when using GCM as noted in section 8.4.

 

The current language w= as added to resolve issue #28 http://trac.t= ools.ietf.org/wg/jose/trac/ticket/28 and is a result of a good bit of d= iscussion with Michael Peck, Jim Schaad, and others in the working group on= the JOSE mailing list between June 2013 and August 2013, with the issue being closed by Jim in October 2013.<= o:p>

 

I recognize that of th= e problem here is that the security considerations actually vary by algorit= hm and yet this subsection is trying to provide general guidance.

 

Is there a specific wo= rding change that you’d like to propose that would weaken the advice = when it’s OK to weaken it, but not in any other circumstances?

 

Section 8.8: I believe the advice in this section is= too weak. It is generally bad practice to derive cryptographic keys from p= asswords as passwords almost never have adequate entropy. Where possible, i= t would be better to have a strong (i.e. randomly chosen) cryptographic key associated with an entity and the= n use the password to acquire that cryptographic key. There are a number of= means for doing that, including having the strong key encrypted with the p= assword (or XORed with it) stored someplace the entity can access it, by having a server that will return th= e key based on a provided password, or with a strong password authenticatio= n protocol. Deriving the key from a password using PBES should be a last re= sort and demanding a longer password to derive a 256 bit key is only fooling yourself... you are never likely t= o get more than 64 bits of entropy.

 

Note that password-bas= ed encryption, as used by this specification, does employ a randomly chosen= content encryption key, and uses the password-based encryption only to enc= rypt the CEK.  Does that alleviate your concerns?  If not, could you supply specific proposed wording changes= that would?

 

        &nbs= p;       --Charlie

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thanks again,=

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

--_000_4E1F6AAD24975D4BA5B16804296739439AE76076TK5EX14MBXC294r_--