Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06

Richard Barnes <rlb@ipv.sx> Tue, 02 December 2014 22:11 UTC

Return-Path: <rlb@ipv.sx>
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 2ED061A6F05 for <secdir@ietfa.amsl.com>; Tue, 2 Dec 2014 14:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 2q9bSGyA9VOU for <secdir@ietfa.amsl.com>; Tue, 2 Dec 2014 14:11:20 -0800 (PST)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384261A1BFE for <secdir@ietf.org>; Tue, 2 Dec 2014 14:11:20 -0800 (PST)
Received: by mail-vc0-f177.google.com with SMTP id ij19so6244447vcb.36 for <secdir@ietf.org>; Tue, 02 Dec 2014 14:11:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g9/EkIWc3qlx4SgPGpu91er8VvuQI3uIdajzs+e53kU=; b=WbdM1EhIIOyua2PvaKXU1B+mXwqwNsjYGTzBHP6WHDlle3OWcPq0jLHb18spgWbePI yS7AzFHHfD8RHgoWwjethfwuSbr31K20vYEzIuUszgWhAKN/31bceIjobedU5LM+bQxh MI24eKMs0q7vWytQMRHZCtPssok0KRbO7/ENtXc+bgNUJ62M+p4n/XXzUQeAc7w2if/X ZREE/FmlH4rb0igrYXNgeMD7wq8ltY+qripvSQcquC5Y5eopgObVVz1ruzRTkHJhmAgb fOwihb337qh84Z9fMaXYojNoXsYXgcLcJWHKaYQKWL4r2d2aHWTQDgfocNqmtwBRsdbm TjfA==
X-Gm-Message-State: ALoCoQln2uyORKlfNO2aXAqFoEhj69aTY0ZXq2lDCB0neObT7Ewa58GMItdHESINxh4jKEIQklCY
MIME-Version: 1.0
X-Received: by 10.220.168.193 with SMTP id v1mr1020436vcy.39.1417558279442; Tue, 02 Dec 2014 14:11:19 -0800 (PST)
Received: by 10.31.149.1 with HTTP; Tue, 2 Dec 2014 14:11:19 -0800 (PST)
In-Reply-To: <547E36ED.1020205@cisco.com>
References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com>
Date: Tue, 2 Dec 2014 14:11:19 -0800
Message-ID: <CAL02cgQHtEYfrmOXxurOCpjQ5KpfZAP1PaGotoXaLegjFk86-Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b5d450eb1e909050943016d
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QBuDv0xLdgDVyIi92D9xnGbLxT0
Cc: draft-ietf-jose-cookbook.all@tools.ietf.org, The IESG <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>
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:11:25 -0000

On Tue, Dec 2, 2014 at 2:02 PM, ⌘ Matt Miller <mamille2@cisco.com> wrote:

> -----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.
>
>
> > • 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.
>

It's also worth noting that of all of the CMS / S/MIME deployments that
have existed for many years, none of them apply integrity protection to the
CMS parameters that are equivalent to these JOSE parameters.

--Richard



>
> > 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/nlfFwmS
> JFGOCww9xOjc2PcdWh4XWh0325abNxc6iMLdiphbQXsad1eB/g5Zg/zXy/fRwv25
> M7YMiaiAa2YAEDyogkMvX1ErQyoN3I9KKcAsxqQmftjpsosyeyfIi0KBJ+yNF8+X
> RNvR/wmzEeBjnJpoVCOI00gw5Zb9cjdTZAePrVJkm3wqUx0u98Rtj/Ws5P4LppWF
> jV7XJAkSo9yOZkfXYXUIArpLAtzgob/wfvEy32ESIzlDbQVI/fB7TeaowrM68xJj
> 7MEC1iATNW1KGWLnnt8VHY6x+qhH3tz+lyt+Qj5Hmr/BWCu0Rj12i2rbCh23SY4=
> =4rNI
> -----END PGP SIGNATURE-----
>
>