Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
⌘ Matt Miller <mamille2@cisco.com> Mon, 20 October 2014 16:58 UTC
Return-Path: <mamille2@cisco.com>
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 879FE1A8759; Mon, 20 Oct 2014 09:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.011
X-Spam-Level:
X-Spam-Status: No, score=-13.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_39=0.6, 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 L6L5W2Wcc1Bn; Mon, 20 Oct 2014 09:58:02 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E581A885E; Mon, 20 Oct 2014 09:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15132; q=dns/txt; s=iport; t=1413823501; x=1415033101; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jY0MiyVsZ3oFCpnIJTeMbsLz2QLcPEqYmDHg/elueyQ=; b=WV9F3l6XThsYE0XGs2srCmscFNNOT/8ok/PkFxV2YRtpPclfJrcmqhBx 0ZY8FXtDRjBpX/tEZW4fzd8r3Ibb3N/ohImfEmQAnRH3TXcVBWmD4W8xj nItrM0I9alcNQO/Feo8JX5udUdl+9smh3VNfmTFEwszi3uGSjUO3AlxU8 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsFAOs6RVStJA2H/2dsb2JhbABSAQmDDlNYBIMCwA6JEAyHSwKBExYBfYQCAQEBAwEBAQEgDwE4AwoBBQcECw4DBAEBAQICBRYEBAMCAgkDAgECARUfCQgGAQwBAwICAQEFiC4IDbFYlCoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSyOQwYBCQIBChIzBwaCcYFUBYUVgRiFNYplgXiFG4EwPIMKgnI7iX6EAYIAHhaBYiIrAYEHJByBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="364782431"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 20 Oct 2014 16:45:00 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9KGj06d000889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 16:45:00 GMT
Received: from [10.129.24.59] (10.129.24.59) by xhc-rcd-x08.cisco.com (173.37.183.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Oct 2014 11:44:59 -0500
Message-ID: <54453C10.2070005@cisco.com>
Date: Mon, 20 Oct 2014 10:45:04 -0600
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: Richard Barnes <rlb@ipv.sx>, Mike Jones <Michael.Jones@microsoft.com>
References: <20141002042150.11117.29199.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C55@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgRSufwEk1eF=AFOXMSzkWpSTRbdtBX9yMOtkMN58uH1zQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439BAFAD6E@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgQipR7b8AgOtopgkj4TJjLivWfYU+4tWA35Oqwvw3cRjw@mail.gmail.com>
In-Reply-To: <CAL02cgQipR7b8AgOtopgkj4TJjLivWfYU+4tWA35Oqwvw3cRjw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.129.24.59]
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/sFJLOgsMe601TLZ6Z3aurCb6yvE
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-signature@tools.ietf.org" <draft-ietf-jose-json-web-signature@tools.ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Oct 2014 16:58:05 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/20/14, 10:15 AM, Richard Barnes wrote: > > > On Sat, Oct 11, 2014 at 5:14 PM, Mike Jones > <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> > wrote: > >> From: Richard Barnes [mailto:rlb@ipv.sx <mailto:rlb@ipv.sx>] >> Sent: Friday, October 10, 2014 3:20 PM To: Mike Jones Cc: The >> IESG; jose-chairs@tools.ietf.org > <mailto:jose-chairs@tools.ietf.org>; jose@ietf.org > <mailto:jose@ietf.org>; > draft-ietf-jose-json-web-signature@tools.ietf.org > <mailto:draft-ietf-jose-json-web-signature@tools.ietf.org> >> Subject: Re: [jose] Richard Barnes' Discuss on > draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT) >> >> On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones > <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> > wrote: >> Thanks for your review, Richard. I'm repeating my previous > responses from my Thursday reply, but this time using ">" quoting > rather than colors, for better readability by people not using > HTML-enabled mail readers... >> >>> -----Original Message----- From: jose >>> [mailto:jose-bounces@ietf.org > <mailto:jose-bounces@ietf.org>] On Behalf Of Richard Barnes >>> Sent: Wednesday, October 01, 2014 9:22 PM To: The IESG Cc: >>> jose-chairs@tools.ietf.org > <mailto:jose-chairs@tools.ietf.org>; jose@ietf.org > <mailto:jose@ietf.org>; draft-ietf-jose-json-web- >>> signature@tools.ietf.org <mailto:signature@tools.ietf.org> >>> Subject: [jose] Richard Barnes' Discuss on > draft-ietf-jose-json-web-signature-33: >>> (with DISCUSS and COMMENT) >>> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-jose-json-web-signature-33: Discuss >>> >>> When responding, please keep the subject line intact and reply > to all email >>> addresses included in the To and CC lines. (Feel free to cut > this introductory >>> paragraph, however.) >>> >>> >>> Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found >>> here: >>> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/ > >>> >>> >> >>> >>> >>> > ---------------------------------------------------------------------- > > > >> DISCUSS: >>> > ---------------------------------------------------------------------- > > > >> >>> Overall, this document is in much more solid shape than when >>> it > began. >>> Thanks to the WG for a lot of hard work. I only have two > remaining concerns, >>> which should hopefully be easy to address. >>> >>> Section 7.2. I've had several implementers trying to use JWS >>> in the JSON > serialization ask why >>> it was necessary to include a "signatures" array in cases >>> where there's only one signer. It seems like this is going to >>> be a major barrier to deployment and re- use, so I would >>> propose including the following text: >>> >>> """ In cases where the JWS has been signed by only a single >>> signer, the "signatures" array will contain a single object. In >>> such cases, the elements of the single "signatures" object MAY >>> be included at the top level of the JWS object. A JSON- >>> formatted JWS that contains a "signatures" field MUST NOT >>> contain a "protected", "header", or "signature" field, and >>> vice versa. """ >>> >>> This may also require some other changes where "signatures" is >>> relied on, e.g., in Section 9 of the JWE spec. >> This was previously proposed (I believe during the Denver >> interim meeting) and rejected by the working group because it >> complicates both producers and parsers by introducing an >> unnecessary special case. Currently, by design, whether there >> are single or multiple signatures, the same syntax is used. Your >> proposal would use a different syntax in the single signature >> case than in the multiple signature case. This is likely to >> result in implementation bugs and inconsistencies. >> >> This assertion of complexity is bogus. Have you implemented >> this syntax, or can you point me to someone who has, and has had >> problems? I have implemented it and I'm asking for the simpler >> syntax. I've gotten the same request from others, for JWE. > > I'm not saying that anything is insurmountable. I'm saying that > having two equivalent syntaxes in the JSON Serialization for the > same thing is going to make it more likely that some > implementations won't correctly support both of them. For those > following along, those two syntaxes would be: > > { "payload":"<payload contents>", "signatures":[ > {"protected":"<integrity-protected header 1 contents>", > "header":<non-integrity-protected header 1 contents>, > "signature":"<signature 1 contents>"}] } > > and > > { "payload":"<payload contents>", > "protected":"<integrity-protected header 1 contents>", > "header":<non-integrity-protected header 1 contents>, > "signature":"<signature 1 contents>" } > > > It's worth noting that the multi-signer case reduces to the > single-signer case, e.g.: > > <script> var JWS = get_jws(); if ("signatures" in JWS) { // i = > index of a signature we'll use JWS.protected = > JWS.signatures[i].protected JWS.header = JWS.signatures[i].header > JWS.signature = JWS.signatures[i].signature } else if (! > ("signature" in JWS) && (("protected" in JWS) || ("header" in > JWS))) { throw "malformed JWS"; } var result = > validate_single_signer_jws(JWS) </script> > > Or copy "payload" up into each signature object. Or iterate > through signatures and see which ones work. Either way, you're > going to build this with a "verify single signature" primitive. > > > > Is your motivating use case a profile of the JSON Serialization in > which multiple signatures aren't used or supported, and so for > which the array notation would always be superfluous syntax? Are > you concerned that if this profile becomes the predominant use > case, that some/many implementations wouldn't implement the more > general multi-signature syntax (or would implement it incorrectly, > since it would normally not ever be used or tested)? > > > If you look at existing uses for signed objects (such as they are), > single-signer is by far the dominant use case, so requiring the > multiple signer notation is would almost always be superfluous > syntax. > > I'm not all that concerned about support for multi-sig. If > implementations care about it, it will get built. And because of > the way this has been designed, it's easy to build once you've got > the single-signer version (see above). > > > > I'd love to hear others in the working group chime in on this > topic... > As I think I've said in previous discussions about the JSON serialization, I can live with something verbose *BUT* would rather like a lighter syntax for the single-sig JSON serialization. It's by far the most common usecase, so optimizing for it seems like a good thing. >>> Section 6. """ These Header Parameters MUST be integrity >>> protected if the information that they convey is to be >>> utilized in a trust decision. """ This smells really fishy to >>> me. What's your attack scenario? I'm pretty certain that >>> there's no way any of these fields can be altered in such a way >>> that (1) the signature will validate, and (2) the recipient >>> will accept a key it shouldn't. By way of contrast, CMS >>> doesn't sign the certificate fields, and the Certificate >>> payload in TLS is only signed as a side effect of the >>> protocol's verification that the remote end has been the same >>> through the whole handshake (which doesn't apply here). >> >> The attack scenario is trivial to describe. If an attacker can >> change information used in a trust decision, the trust decision >> has no validity. Unless the information is integrity-protected, >> the attacker could change the non-integrity-protected portions >> of the JWS in an undetectable way. >> >> That's hand waving, not an attack scenario. Allow me to >> elaborate on this: >> >> There is no possible attack scenario for the key identifiers >> that identify a *key* (vs. a cert) -- jwk, jku, and kid. For >> any given signed object, there is exactly one key that can >> validate the signature (otherwise the crypto is broken). If the >> attacker changes the validation key, then the signature won't >> validate. So there is no need to integrity protect these headers, >> since there's no point to the attacker changing them. RFC 2634 >> actually has text to this effect: >> >> """ The first version of this attack is a simple denial of >> service attack where an invalid certificate is substituted for >> the valid certificate. This renders the message unverifiable, as >> the public key in the certificate no longer matches the private >> key used to sign the message. """ > > It's not clear to me that enabling the attacker to substitute keys > and get the recipient to attempt to validate the signature with a > key of the attacker's choosing doesn't constitute at least a > portion of a viable attack scenario. It may or may not (knowing > for sure is beyond my specific cryptographic expertise in this > area) and it may not now but may be in the future (when new > attacks are created). Requiring these parameters to be integrity > protected when used in a trust decision does no harm and may do > substantial good. > > > It seems pretty clear to me :) Everything involved in signature > verification is public, so anything the attacker could do by > tricking a third party into verifying he could just as well do > himself. The only exception to this would be if the verification > were somehow a side-channel for something else happening on the > verifier's machine, which seems pretty outlandish. > > > >> With regard to the certificate identifiers ("x5u", "x5c", "x5t", >> and "x5t#S256"), the risks that Jim points out [RFC2634, Section >> 5] are real, but only apply in certain narrow circumstances. >> Namely, the only time a risk arises is when two certificates >> have been issued for the same public key, with different >> attributes. This is exceedingly rare in practice, and all current >> secure messaging systems get along fine without protection >> against this attack. And it might not even be an attack -- you >> could envision cases with "x5u" where the signer purposely >> presents different certificates to different relying parties! So >> the blanket requirement that these fields MUST be integrity >> protected is not appropriate. It is only required for certain >> special situations using certificates. Proposed revision: >> Delete: "These Header Parameters MUST be integrity protected if >> the information that they convey is to be utilized in a trust >> decision." > > Researching the history a bit more, this text was added to address > issue #104 http://trac.tools.ietf.org/wg/jose/trac/ticket/104 > raised by Jim Schaad. Unless Jim agrees that it is now somehow > unnecessary, I don't believe that it's reasonable for us to now > remove it. Also, see Jim's related comments about trust statements > and trust decisions in issue #74. > > > I would note that issue #104 was closed without any discussion on > the list (AFAICT). And that issue only related to "jku", so the > extension to all the other fields is unnecessary. See my response > to Jim for why it's not necessary for "jku" either. > > As far as issue #74, that appears to be about not using the URI as > an element of the trust decision unless the identity in the URI is > authenticated. I read that as to mean that the subject of the URI > authenticated itself, e.g., using HTTPS server authentication. > > > > >> Add new paragraph: "In situations where multiple certificates >> with > different attributes may be issued over the same public key, there > is a risk that one of these certificates may be substituted for > another. In such situations, the creator of a JWS object MUST > integrity protect the "x5u", "x5c", "x5t", and "x5t#S256" > attributes, if present." >> >> For what it's worth, Sean had us add language in a number of > places that basically said that information is only as trustworthy > as its source and the means by which it is obtained. If I > remember correctly, this was one of those places. >> >>> > ---------------------------------------------------------------------- > > > >> COMMENT: >>> > ---------------------------------------------------------------------- > > > >> >>> Section 2. In the definition of "Unsecured JWS", it would be >>> good to note > that this requires >>> "alg" == "none". >> >> OK >> >>> Section 3.3. Why doesn't this section have a JSON-encoded form >>> as well? >> >> Because it's meant to be a simple introductory example to help > people get their head around the concept - not a complete > tutorial. Other examples of JSON-encoded objects are found > elsewhere in the document and lots of them are found in > draft-ietf-jose-cookbook. >> >>> Appendix A.5. I would prefer if this example could be removed. >>> JWT is the > only use case for >>> Unsecured JWS right now, and there's already an example in >>> that > document. >> >> Mike> Given that it's important that implementers using them > understand Unsecured JWSs, there is motivation to retain the > example. I'd be interested in what others in the working group > think, given that there was substantial support for retaining this > functionality when its removal was proposed. >> >>> Thanks for Appendix C. FWIW, it has been implemented: >>> > http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoBuffer.cpp#85 > > > > >> You're welcome. >> >>> _______________________________________________ jose mailing >>> list jose@ietf.org <mailto:jose@ietf.org> >>> https://www.ietf.org/mailman/listinfo/jose >> >> Thanks again! -- Mike > > -- Mike > > > > > _______________________________________________ jose mailing list > jose@ietf.org https://www.ietf.org/mailman/listinfo/jose > - -- - - 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 iQEcBAEBCgAGBQJURTwQAAoJEDWi+S0W7cO1bH0IALWtE7ZjYJgjtxeXtZCbHK1a XZX1BcInXWEJa09tddnfU4kkHM26bcwO0KWUEcAgqaJGZawKFdB2SxpLnG3U1Cm3 LMzBtfYF1VhZgoh4YomuQkT8rflooy15PvlGBbbENjiVl/6KZiZ745lN86EEuXvI +qX9Ltjf3VfupqMYafE79FP8yO+18O8EaYY66+njPQYm0kvTQQ1c6RJbAYlxjo4M Zr5cmpTjEvS3wspHfE4fBiEp/kbjpGJ57jKSpKOK1hocibu6uMeEc9ImWWOgT6+5 u/ylFqkwMf8mvI3rLWIczJBSE/zl2G7cX/h+DJdustdaFjubYiMQH/YmMhWRcPw= =sxXV -----END PGP SIGNATURE-----
- [jose] Richard Barnes' Discuss on draft-ietf-jose… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… ⌘ Matt Miller
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones