Re: [secdir] JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31

[Mike Jones <[e-mail]>]

Replies inline below...

From: Stephen Kent [mailto:[e-mail]]
Sent: Monday, September 15, 2014 7:56 AM
To: Mike Jones; Kathleen Moriarty; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31

Mike,

Sure.  Here's an analysis of the requirements about duplicate member names.

There could be two very different kinds of objections to the present text:
A.  People think we have the semantics for duplicate identifiers wrong.
B.  People think we should explain the current semantics for duplicate identifiers more clearly.

I sure hope that we're dealing with B and not A.  Stephen, which is the nature of your critique of this text?
C- don't accept duplicate IDs, is what I was hoping for.

I noted why allowing a recipient to accept a dup name, and use just the last instance, will
likely lead to such behavior being perpetuated, based on PKIX experience.

So you're advocating this alternative from the analysis, correct?
1.  Require producers not use duplicate members and require consumers to reject inputs with duplicate member names.
Pros:  This is the most locked-down, consistent, and alternative.
Cons:  Real JSON parsers don't all reject duplicate inputs.  If we force people to write custom parsers, this will result in exploitable bugs (and some just won't do it and won't be conformant).

The primary reason that the working group changed from this alternative in draft -12 in July 2013 to the present one is that it allows JSON parsers as actually deployed and supported to be used.  The argument made then was that forcing people to write a custom parser to reject duplicate member names is likely to create security bugs, since insufficiently locked down parsers are a fertile area for security vulnerabilities.  It was thought that it was better to have people using well-maintained, standard parsers and count on producers to not emit duplicate member names in the first place.  Is there some aspect of this reasoning that doesn't seem convincing to you, Stephen?

As for perpetuating the behavior, it's not clear to me that the behavior will ever start, since producers can't use duplicate member names and consumers are allowed to reject them.  Thus, producers can't count on consumers accepting the illegal inputs, and so have a strong disincentive against ever producing them.  Is there something I'm missing here?

Also, in a reply to Tim, I think you argued that people have already implemented JOSE and so
we ought not make any changes at this late stage. If that's what you said, I disagree emphatically.
The IETF always warns implementers that specs may change until an RFC is published, and thus
one implements a pre-RFC spec at risk.

You apparently misunderstood the point of my reply to Tim.  I wasn't saying that changes aren't possible.  I was saying that we want JOSE to be usable by people now - not just several years in the future when parsers for a more locked-down JSON dialect may become available.

Steve

                                                            -- Mike