Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9815821F9E77 for ; Thu, 27 Jun 2013 10:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKVpAIJYcJ5D for ; Thu, 27 Jun 2013 10:11:09 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E56721F9E75 for ; Thu, 27 Jun 2013 10:11:09 -0700 (PDT) Received: from Philemon (mccpool-66-89.ci.monterey.ca.us [205.155.66.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id DB4D52C9FE; Thu, 27 Jun 2013 10:11:08 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'John Bradley'" , "'Tim Bray'" References: <061.bb7bbe0b618ec6b74904f48bdb9bb312@trac.tools.ietf.org> <076.a597050ecb4fb25084cec65f7174dc7e@trac.tools.ietf.org> <033b01ce729b$26ff5c90$74fe15b0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436789B4CC@TK5EX14MBXC283.redmond.corp.microsoft.com> <03b401ce72e5$002c65f0$008531d0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436789D4EA@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1151BE45737@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151BEDDD3C@WSMSG3153V.srv.dir.telstra.com> <16F5858A-B77F-498B-9296-A42F84D5244D@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943678A009C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943678A009C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 27 Jun 2013 10:10:12 -0700 Message-ID: <04ba01ce7359$2f946120$8ebd2360$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04BB_01CE731E.8337FA20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGqOaFgm5bSrTowyJkuz8ggVcVAJQJ0/9dvAtXnsooCfmP1+wE/Pt+eAksevJwBgJ6Q/AKiJ4UHAcTplCQBWG5bvQLZ0+mqAXMi1n4BLTjXupjRzw7Q Content-Language: en-us Cc: "'Manger, James H'" , jose@ietf.org, draft-ietf-jose-json-web-signature@tools.ietf.org Subject: Re: [jose] #27: member names MUST be unique needs additional text X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:11:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04BB_01CE731E.8337FA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Except for the parsers which only return the nth name (according to the JSON list they exist) it at least provides a degree of predictability. The JSON list would point out that you want to allow duplicate field names for the purposes of putting comments into output using the name "//". From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, June 27, 2013 9:43 AM To: John Bradley; Tim Bray Cc: Manger, James H; Jim Schaad; jose@ietf.org; draft-ietf-jose-json-web-signature@tools.ietf.org Subject: RE: [jose] #27: member names MUST be unique needs additional text I've come to believe that James' proposed language does a good job of making security-appropriate restrictions while allowing the use of existing parsers. It was: A creator of a JOSE message MUST NOT put duplicate names in any JSON object in a JOSE header. To prevent attacks where a JOSE message is interpreted as different valid messages by different recipients, each recipient MUST either reject messages with duplicate names or accept only the last name. I might change "or accept only the last name" to "or use a parser that always uses the lexically last name for any duplicate member names, per [ECMAScript]" for clarity, but the intent is the same. Would that work for people? -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Thursday, June 27, 2013 8:49 AM To: Tim Bray Cc: Manger, James H; Mike Jones; Jim Schaad; jose@ietf.org; draft-ietf-jose-json-web-signature@tools.ietf.org Subject: Re: [jose] #27: member names MUST be unique needs additional text The problem is not wanting to leave a hole for malicious signers to create JWT that may be misinterpreted by the receiver. Accidental interop problems from bad signers are not a big concern for me and are covered by MUST NOT emit dups. Accepting malformed JSON as the envelope may lead to real security issues. This may be more of an issue for the JSON encoding than the compact as there you need to be careful the body you process for the signature is the body that the application uses. What happens if you receive. {"protected":", "unprotected":", "payload":"", "payload":"" "signatures":[ {"header":"", "signature":""}, ... {"header":"", "signature":""}], } If the JOSE library validates on the first version of "payload" and the application using a different JSON parser only sees the second "payload" we have a wrapping attack similar to xmldsig. I can't off the top of my head think of what you could do in the compact serialization that would lead to a successful attack given that the signature is over the base64url encoded segments, that prevents attackers from modifying the JSON while maintaining integrity. It is a real issue for the JSON serialization though. John B. On 2013-06-27, at 11:20 AM, Tim Bray wrote: The approach just seems wrong. If we require that conforming implementations MUST NOT emit dupes, then authors of receiving software can just pick the best-performing parser with the nicest API, because they *all* perform correctly when there are no dupes. Who's going to own the responsibility for making the authoritative finding that of the many JSON parsers in the Java ecosystem, these ones, but not those ones, are usable in JOSE applications? And suppose one that has been previously OK is quietly optimized on GitHub to run 30% faster and as a side-effect silently ignores dupes? The benefit of using JSON is that there is widely deployed software to handle it. It is a known problem that sloppy spec drafting has allowed various kinds of problems to occur when dupe keys are received. "Doctor, it hurts when I do this." "So... don't do that." Are we also going to specify the behavior of receiving software when the JSON has a misplaced quotation mark? A missing trailing "}"? -T On Wed, Jun 26, 2013 at 11:29 PM, Manger, James H wrote: Most JSON libraries that silently accept [sob] dupe keys at least consistently use the last key. Allowing just that behaviour (or rejecting dupes), while forbidding acceptance of a non-last dupe (eg first key), is safe and allows most JSON libraries to be used. Since this accepts most libraries I think it is practical. Hence I suggest: > A creator of a JOSE message MUST NOT put duplicate names in any JSON > object in a JOSE header. > To prevent attacks where a JOSE message is interpreted as different > valid messages by different recipients, each recipient MUST either > reject messages with duplicate names or accept only the last name. This isn't "truly predictable" as a message with dupes might be accepted or rejected. The crucial point is that if a message is accepted it is predictable. -- James Manger From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, 27 June 2013 4:16 PM To: Manger, James H Cc: Mike Jones; Jim Schaad; jose@ietf.org; draft-ietf-jose-json-web-signature@tools.ietf.org Subject: Re: [jose] #27: member names MUST be unique needs additional text Well, you have a practical problem in that most implementers will want to use a standard JSON library, which is good practice because it will be well-debugged, and most libraries [sob] silently take care of dupe keys and don't have a way to tell the client software what happened. So if you want truly predictable behavior, you're forcing the use of hand-constructed JSON parsers. And that sucks, because getting good performance in JSON parsing is surprisingly hard, with dramatic performance differences between implementations. So you're forcing receiving software which wants to be conformant to use a hand-rolled parser which will probably have lousy performance and have other bugs which in fact may compromise security more than dupe-key tricks could. -T On Wed, Jun 26, 2013 at 10:39 PM, Manger, James H wrote: > I think it's a nice clean minimal solution to say that producers MUST > NOT generate dupes, end of story. I don't think saying anything beyond > that adds value. -T Clean and minimal that may be, but it ignores the security issue. We don't want a malicious producer (who is so malicious they ignore a MUST) to create JOSE messages that a JOSE-compliant security layer accepts as "benign interpretation #1" so it passes the message on to the JOSE-compliant backend app that acts on "nasty interpretation #2". -- James Manger ------=_NextPart_000_04BB_01CE731E.8337FA20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Except for the parsers which only return the nth name (according to = the JSON list they exist) it at least provides a degree of = predictability.

 

The JSON list would point out that you want to allow duplicate field = names for the purposes of putting comments into output using the name = “//”.

 

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Thursday, June 27, 2013 9:43 AM
To: John Bradley; Tim = Bray
Cc: Manger, James H; Jim Schaad; jose@ietf.org; = draft-ietf-jose-json-web-signature@tools.ietf.org
Subject: RE: = [jose] #27: member names MUST be unique needs additional = text

 

I’ve come to believe that James’ proposed language does a = good job of making security-appropriate restrictions while allowing the = use of existing parsers.  It was:

 

A creator of a JOSE message MUST NOT put duplicate names in any JSON = object in a JOSE header.  To prevent attacks where a JOSE message = is interpreted as different valid messages by different recipients, each = recipient MUST either reject messages with duplicate names or accept = only the last name.

 

I might change “or accept only the last name” to = “or use a parser that always uses the lexically last name for any = duplicate member names, per [ECMAScript]” for clarity, but the = intent is the same.

 

Would that work for people?

 

           &nbs= p;            = ;            =             &= nbsp;           -- = Mike

 

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com] =
Sent: Thursday, June 27, 2013 8:49 AM
To: Tim = Bray
Cc: Manger, James H; Mike Jones; Jim Schaad; jose@ietf.org; draft-i= etf-jose-json-web-signature@tools.ietf.org
Subject: Re: = [jose] #27: member names MUST be unique needs additional = text

 

The problem = is not wanting to leave a hole for malicious signers to create JWT that = may be misinterpreted by the receiver.  Accidental interop problems = from bad signers are not a big concern for me and are covered by MUST = NOT emit dups.

 

Accepting malformed JSON as the envelope may lead to = real security issues.

 

This may be more of an issue for the JSON encoding = than the compact as there you need to be careful the body you process = for the signature is the body that the application = uses.

 

What happens if you = receive.

 

{"protected":<integrity-protected=
 shared header contents>",
      =
"unprotected":<non-integrity-protected shared header =
contents>",
      =
"payload":"<original payload =
contents>",
      =
"payload":"<bad payload contents inserted by =
attacker>"
      =
"signatures":[
       =
{"header":"<per-signature unprotected header 1 =
contents>",
        =
"signature":"<signature 1 =
contents>"},
       =
...
       =
{"header":"<per-signature unprotected header N =
contents>",
        =
"signature":"<signature N =
contents>"}],
     =
}

 

If the JOSE library validates on the first version of = "payload" and the application using a different JSON parser = only sees the second "payload" we have a wrapping attack = similar to xmldsig.

 

I = can't off the top of my head think of what you could do in the compact = serialization that would lead to a successful attack given that the = signature is over the base64url encoded segments, that prevents = attackers from modifying the JSON while maintaining = integrity.

 

It is a real issue for the JSON serialization = though.

 

John B.

 

On 2013-06-27, at 11:20 AM, Tim Bray <tbray@textuality.com> = wrote:

 

The approach just seems = wrong.  If we require that conforming implementations MUST NOT emit = dupes, then authors of receiving software can just pick the = best-performing parser with the nicest API, because they *all* perform = correctly when there are no dupes. 

Who’s going to = own the responsibility for making the authoritative finding that of the = many JSON parsers in the Java ecosystem, these ones, but not those ones, = are usable in JOSE applications?  And suppose one that has been = previously OK is quietly optimized on GitHub to run 30% faster and as a = side-effect silently ignores dupes? 

The benefit of using = JSON is that there is widely deployed software to handle it.  It is = a known problem that sloppy spec drafting has allowed various kinds of = problems to occur when dupe keys are received. “Doctor, it hurts = when I do this.” “So... don’t do = that.”

Are we also going to specify the behavior = of receiving software when the JSON has a misplaced quotation = mark?  A missing trailing = “}”?

 -T

 

 

On Wed, Jun 26, 2013 at 11:29 PM, Manger, James H = <James.H.Manger@team.telstra.com> = wrote:

Most JSON libraries that silently accept [sob] dupe keys at least = consistently use the last key. Allowing just that behaviour (or = rejecting dupes), while forbidding acceptance of a non-last dupe (eg = first key), is safe and allows most JSON libraries to be used. Since = this accepts most libraries I think it is practical.

 

Hence I suggest:

 

>   A creator of a JOSE message MUST NOT put = duplicate names in any JSON

> object in a JOSE header.

>   To prevent attacks where a JOSE message is = interpreted as different

> = valid messages by different recipients, each recipient MUST = either

> reject messages = with duplicate names or accept only the last = name.

 

This isn’t “truly predictable” as a message with = dupes might be accepted or rejected. The crucial point is that if a = message is accepted it is predictable.

 

--

James Manger

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = 27 June 2013 4:16 PM
To: Manger, James H
Cc: Mike = Jones; Jim Schaad; jose@ietf.org; draft-ietf-jose-json-web-signature@tools.ietf.org


Subject: Re: [jose] #27: = member names MUST be unique needs additional = text

 

 

Well, you have a practical problem in that most = implementers will want to use a standard JSON library, which is good = practice because it will be well-debugged, and most libraries [sob] = silently take care of dupe keys and don’t have a way to tell the = client software what happened. So if you want truly predictable = behavior, you’re forcing the use of hand-constructed JSON parsers. = And that sucks, because getting good performance in JSON parsing is = surprisingly hard, with dramatic performance differences between = implementations. So you’re forcing receiving software which wants = to be conformant to use a hand-rolled parser which will probably have = lousy performance and have other bugs which in fact may compromise = security more than dupe-key tricks could.  = -T

 

On Wed, Jun 26, 2013 at 10:39 PM, Manger, James H <James.H.Manger@team.telstra.com> = wrote:

> I think it’s a nice clean minimal solution to = say that producers MUST
> NOT generate dupes, end of story.  = I don’t think saying anything beyond
> that adds value. = -T

Clean and minimal that may be, but it ignores the security = issue. We don't want a malicious producer (who is so malicious they = ignore a MUST) to create JOSE messages that a JOSE-compliant security = layer accepts as "benign interpretation #1" so it passes the = message on to the JOSE-compliant backend app that acts on "nasty = interpretation #2".

--
James = Manger

 

 

 

------=_NextPart_000_04BB_01CE731E.8337FA20--