Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06
"Jim Schaad" <ietf@augustcellars.com> Tue, 02 December 2014 22:43 UTC
Return-Path: <ietf@augustcellars.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 1FAEE1A1ACE; Tue, 2 Dec 2014 14:43:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RLNkqJOniT-y; Tue, 2 Dec 2014 14:43:56 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7091A1AB8; Tue, 2 Dec 2014 14:43:56 -0800 (PST)
Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A645C38F45; Tue, 2 Dec 2014 14:43:55 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: '? Matt Miller' <mamille2@cisco.com>, '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>
In-Reply-To: <547E36ED.1020205@cisco.com>
Date: Tue, 02 Dec 2014 14:43:29 -0800
Message-ID: <03c001d00e81$65300400$2f900c00$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQCfLK/cFUOZt7KXRlpowFM5JqM6CgBG564yntxxgwA=
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ChxPsDc22-rDxav5cEo55piHVnA
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, 02 Dec 2014 22:43:59 -0000
> -----Original Message----- > From: ? Matt Miller [mailto:mamille2@cisco.com] > Sent: Tuesday, December 02, 2014 2:02 PM > To: Yaron Sheffer; IETF Security Directorate; The IESG; draft-ietf-jose- > cookbook.all@tools.ietf.org > Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Yaron, > > Thank you very much for the review. My other comments are inline. > > On 11/22/14, 12:39 PM, Yaron Sheffer wrote: > > 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. > > > > This document contains a large set of examples of JOSE objects: > > JWK, JWS and JWE. The document is purely informational, though in > > "real life", I would expect developers to use it as an authoritative > > source. > > > > Summary > > > > The document is ready to be published, with some issues. > > > > By the way, I really appreciate the large effort that surely went into > > creating this document. > > > > Thank you! It's always great to hear one's efforts are appreciated! > > > Details > > > > 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? > > > (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. > > > > Why invent a new term "octet key", for a simple "symmetric key"? > > Very good point. Will fix in the next revision. > > > > > 4.2: the first sentence discusses PS256, the actual example is > > PS384. > > > > Silly error that I thought I fixed long ago /-: > > Will fix in the next revision. > > > 4.7: "only the JSON serialization" - please clarify which of the > > three serializations is meant. Ditto top of 4.8. > > > > Will fix in the next revision. > > > 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 believe that it makes far more sense to have the private keys as well as the public keys. Historically in S/MIME people stated by trying to decrypt known good messages and then went on to try and encrypt and test against a known good decryption implementation. Additionally, one would of course need to have private keys on the signing side as well. Jim > > > 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. > > > > 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". > > > 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. > > > 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. > > > > Thanks, Yaron > > > > _______________________________________________ secdir > mailing > > list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > And thanks again for the thorough review. > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUfjbtAAoJEDWi+S0W7cO1rSUH/1j3BZKQz5zwo/N9/nlfFw > mS > JFGOCww9xOjc2PcdWh4XWh0325abNxc6iMLdiphbQXsad1eB/g5Zg/zXy/fRw > v25 > M7YMiaiAa2YAEDyogkMvX1ErQyoN3I9KKcAsxqQmftjpsosyeyfIi0KBJ+yNF8+X > RNvR/wmzEeBjnJpoVCOI00gw5Zb9cjdTZAePrVJkm3wqUx0u98Rtj/Ws5P4Lpp > WF > jV7XJAkSo9yOZkfXYXUIArpLAtzgob/wfvEy32ESIzlDbQVI/fB7TeaowrM68xJj > 7MEC1iATNW1KGWLnnt8VHY6x+qhH3tz+lyt+Qj5Hmr/BWCu0Rj12i2rbCh23SY > 4= > =4rNI > -----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