Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06
⌘ Matt Miller <mamille2@cisco.com> Tue, 09 December 2014 18:35 UTC
Return-Path: <mamille2@cisco.com>
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 EB1171A01C6; Tue, 9 Dec 2014 10:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level:
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 lAxPjnzSwKZ9; Tue, 9 Dec 2014 10:35:23 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3195A1A00D1; Tue, 9 Dec 2014 10:35:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7319; q=dns/txt; s=iport; t=1418150123; x=1419359723; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=B90914AsAiu92RSIn8moXMe14oE/sxnQTGX1XC91Q0A=; b=gB7+ZshA13lhsCPPCbeXXFXGcrSgJn2TuM4lmXVV1QI2a8papvqiDZSW lpK0Em3HUpQ3nCxKxV7k28+ycpt/ynlcqC2ah6AIMjaS4jkpydap4vD1C qMsIQCdmRHxCdTljmADXBhItDWNIkDYMYXN1qajOpy2YEbSH7dlnj4JTV s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUFACdAh1StJA2E/2dsb2JhbABZgwZSWASDAcMehgkCgSYWAQEBAQF9hAMBAQQjDwE5CgIRCxgCAgUPBwsCAgkDAgECAUUGAQwGAgEBiDQNwB+XGgEBAQEBAQEBAgEBAQEBAQEBARmBJokkhRolOhiCV4FHBYlCiCSFPIENMIIvghOIDYNeggAcgXJPgQMCHgYcfgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="378839676"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 09 Dec 2014 18:35:22 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB9IZMGE005458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 18:35:22 GMT
Received: from [64.101.72.27] (64.101.72.27) by xhc-rcd-x03.cisco.com (173.37.183.77) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 12:35:21 -0600
Message-ID: <548740F1.4010607@cisco.com>
Date: Tue, 09 Dec 2014 11:35:29 -0700
From: ⌘ Matt Miller <mamille2@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>, IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-jose-cookbook.all@tools.ietf.org
References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com> <5480CD20.6080300@gmail.com>
In-Reply-To: <5480CD20.6080300@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [64.101.72.27]
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lRyIIo8daqW99bc-GCsNgaHZG5Y
Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 18:35:26 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Yaron, I believe < https://tools.ietf.org/html/draft-ietf-jose-cookbook-07 > addresses most of your comments; the exceptions being those points still under discussion (see Jim Schaad's latest reply). Please let me know if I missed anything I thought I fixed. Thank you, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 12/4/14, 2:07 PM, Yaron Sheffer wrote: > Hi Matt, > > Please see my comments below. I have removed much of the original > text, and only left points that need further discussion. > > Thanks, Yaron > > On 12/03/2014 12:02 AM, ⌘ Matt Miller wrote: [...] >>> >>> • Unless I missed it, the document does not mention a machine >>> readable repository of these examples, which I am sure the >>> author has created while writing the draft. Making such a >>> repository publicly available would result in a much more >>> useful resource than the current document, which essentially >>> requires testers to scrape the document when creating their >>> test cases. >>> >> >> You did not miss it; I don't have a such a repository right now, >> but I can put one together. Would something on github.com be >> acceptable, or is there a better suggestion? > > GitHub would be a great place. > >> >>> • (Not a comment to the current document:) I wonder why there >>> is nothing explicit to distinguish a public key from a private >>> key, and they are only distinguished by the presence or absence >>> of several parameters, something that will not be natural to >>> most developers. PEM is doing it very well: "-----BEGIN RSA >>> PRIVATE KEY-----". >>> >>> • 3.4: the text is contradictory re: zero-padding of the value >>> "d". Is it using the minimum number of octets, or exactly 256 >>> octets (for a 2048-bit key)? >>> >> >> The intent is that "d" is not zero-padded, and I overqualified in >> my text. Would the following be acceptable? >> >> For a 2048-bit key, the field "n" is 256 octets in length when >> decoded and the field "d" is not longer than 256 octets in length >> when decoded. >> > > Yes. > >> > [snip] >> >>> • 5.1.1: since this is a "cookbook", we should be using the >>> public key, not the private key. A private key would only be >>> used in rare cases. Similarly 5.2.1. >>> >> >> The private keys are included for both reproduction (which only >> needs the public key) and verification (which necessitates the >> private key). >> >> If I can put an online repository together, I can change the >> examples to just include the public keys; otherwise would the >> following in 5.1 (and 5.2) be sufficient? >> >> Note that only the RSA public key is necessary to perform the >> encryption. However, the example includes the RSA private key >> to allow readers to validate the example's output. >> > > I'm fine with this new text. > >> >>> • 5.3.1: the "plaintext content" is a list of keys, which is >>> either confusing to the reader, or an actual error in the >>> document. >>> >> >> It is not in error. The most common usecase for password-based >> encryption was the import and export of key sets, and the >> Working Group desired a thorough example. >> >> Would it help if the following is added to 5.3? >> >> A common use of password-based encryption is the import/export >> of keys. Therefore this example uses a JWK Set for the >> plaintext content instead of the plaintext from figure 72. >> > > Yes, this would help. > >> >>> • 5.3.5: In the General Serialization version, I don't >>> understand why only the encrypted key is per-recipient. I would >>> expect the PBES2 parameters too (e.g., the salt) to be >>> per-recipient. Presumably each of them is using a different >>> password, and there's no reason to use a common salt. Similarly >>> in 5.4.5. >>> >> >> For compatibility across serializations (compact, general JSON, >> flattened JSON), all of the parameters need to be in the JWE >> Protected Header. In the general serialization, that means only >> the "encrypted_key" field is present for the (presumably) sole >> recipient. >> >> Would it be acceptable if the following were added to 5.3? >> >> Note that if password-based encryption is used for multiple >> recipients, it is expected that each recipient use different >> values for the PBES2 parameters "p2s" and "p2c". >> > > So I still don't understand: don't we need an example that > demonstrates how the JSON structure (or multiple structures) is > generated so that "each recipient use(s) different values"? > > In general I don't understand this "compatibility" thing. > Obviously there are some cases that cannot be expressed in all > serialization types. Otherwise why would we need three of them? > >>> • 5.7: same as above, it makes sense for the per-recipient key >>> to have an ID, rather than the content encryption key >>> (typically an ephemeral key). And then that ID should be in the >>> per-recipient data in 5.7.5. And similarly for 5.8. The later >>> Sec. 5.13 shows a syntax for multiple recipients that's >>> inconsistent with the single-recipient case, which would make >>> sense if we got rid of the array. >>> >> >> For compatibility across serializations (compact, general JSON, >> flattened JSON), all of the parameters need to be in the JWE >> Protected Header. Also, the mixing of "recipients" and >> "encrypted_key"/"header" in the top-level object is not permitted >> for the general serialization. >> > > Still confused. Sorry. > >>> • 5.11: this example seems strange to me - why would anybody >>> NOT want to integrity-protect the key ID and algorithm? I would >>> prefer a more realistic example, or failing that, a >>> recommendation to developers to avoid this practice. Similarly >>> 5.12, which is an even worse idea. >>> >> >> Integrity protection was thoroughly discussed in the JOSE WG. >> While there are some limited attacks possible when some >> parameters are unprotected, the WG felt there were enough use >> cases where these attacks are mitigated through other means that >> integrity protection of the part of all of the header is not >> always required. > > So (personal opinion here) I think the WG took a security risk > that should not have been taken in 2014, for a minor performance > gain. We have seen too many protocols fail because of > integrity-protection shortcuts. Who would have thought you need to > integrity-protect the padding field! The fact that CMS took this > route back in 1999 is sort of irrelevant, as we've all learned a > lot since then. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUh0DxAAoJEDWi+S0W7cO1yn8H/3qu51pBi99f8FmuI/ZyW+9+ LJfToPCcaTlSWqLR14mzApvm2VTgX60R89+ykQzVcvRIqZZvr4gqtJFnNtSUsGgs PWEU837QEi0B/xfLADk6YF8om3B5XR6SX1xS4BSY4+oxh1XjIeRFoNqE2XLcFCd/ P5NLs5NH3ZJS4khKFTgw7dzYBiSWUf+DEOZaPb8vcRVRUy7giJlKbax5u1jQgk9X 1e7+W72rpjSVfd9+cP7Jme4Atz/K7MKawebz+6UsTVRH3dImwg4qy2IggMrGxrba TZXdXE4wxVVlbc768cTjZJPtHwZ/HH/e/sgNrUK66WSrBveoBDf7v8NGu7+pS8w= =3XEs -----END PGP SIGNATURE-----
- [secdir] SecDir review of draft-ietf-jose-cookboo… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-jose-coo… ⌘ Matt Miller
- Re: [secdir] SecDir review of draft-ietf-jose-coo… Richard Barnes
- Re: [secdir] SecDir review of draft-ietf-jose-coo… Jim Schaad
- Re: [secdir] SecDir review of draft-ietf-jose-coo… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-jose-coo… Jim Schaad
- Re: [secdir] SecDir review of draft-ietf-jose-coo… ⌘ Matt Miller
- Re: [secdir] SecDir review of draft-ietf-jose-coo… Yaron Sheffer