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: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= <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-----