Re: [jose] thoughts on header criticality from recent polls

[Mike Jones <[e-mail]>]

Hi Richard,

Responding to your proposal "that we extend (1) by saying that the non-critical headers would not be covered by the header integrity check", I'll note that syntactically separating the critical and non-critical headers was option "B" in the third question of the poll, and would be a pre-requisite to having non-critical members not be covered by the integrity check.  By my count, only 10% of the respondents supported that position.  (I know - repeat after me - the IETF doesn't vote. :))  Possibly more important than the actual numbers, Karen wrote in her reply "I am assuming that we aren't going to define a separate header for non-critical elements."  So I, as an individual, I think that option should be off the table, because I can't see it increasing consensus.

I think it would be more productive to focus the discussion on how we want to handle the (integrity-protected) header parameters that are and aren't critical to understand, and not try to conflate that with not integrity protecting some parts of the message.

                                                            -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Monday, February 25, 2013 2:12 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [jose] thoughts on header criticality from recent polls

Hi Karen,

Thanks for these thoughts.

tl;dr: I'm OK with (1) or (2).  I would propose that we extend (1) by saying that the non-critical headers would not be covered by the header integrity check.

Detailed responses inline below.

--Richard

<snip>
A. Want to be able to define messages with new semantics in future, without any risk that old implementations will misinterpret them with old semantics.

B. Want to be able to *redefine* (or constrain) the semantics of *existing* fields in future, without any risk that old implementations will misinterpret them with old semantics (or without the constraints).

C. Want to prevent large blobs of ignored data appearing in messages, as similar blobs have been used to create hash collisions between legitimate & malicious certificates that use weak algorithms (eg MD5).

D. Want to strongly discourage future extensions (feature-creep), under the philosophy that even well-intentioned extensions tend to do more harm (by adding complexity that is only deployed sporadically) than the good of any new functionality they bring.

E. Loosely coupling clients and servers is generally considered a good thing; but strongly coupling them is more appropriate for a secure message format for [insert a reason here]. A possible reason is that people are too likely to choose to make an extension non-critical for short-term ease of interoperability, instead of making it critical for better long-term security.

>From this list, I believe A is definitely a requirement. I am unclear regarding working group consensus on B, C, and E, and I believe D is not a requirement.

QUESTION: Is there working group consensus on the requirements we are trying to address? Perhaps a short discussion clarifying these would help drive consensus on the overall approach.

Here's my take:

A: This is a requirement.  But it is met trivially by having the new format use new identifier names and marking them critical.

B: This is not a requirement.  It's a bad idea.  Identifiers here are cheap, so if you want new semantics, just use a new identifier.

C: This is a requirement (and a good point), in the sense that we should avoid providing channels that an attacker could use to control the integrity check value on a JW* object.  However, what that argues is that non-critical fields shouldn't be covered by the integrity check, not that they should be ruled out altogether.

D: This is not a requirement, for the reasons you give.

E: This is not a requirement.  Couple of clients/servers is an application-layer issue.



As for possible solutions, we appear to have evolved to the point where we are of two minds:

1) Define a header field that explicitly lists the fields that may be safely ignored if not understood. (Here I am assuming that we aren't going to define a separate header for non-critical elements.)

2) Remain silent on header criticality in the JOSE specifications and leave it up to the various application specifications (possibly providing guidance directed to those applications in the JOSE specs).

I sense that there is more support for the first approach, but I am concerned that there is a significant minority that favor the second approach.

I would personally be OK with either approach.  I would generalize (1) slightly to say "Define a syntax for indicating which fields are critical / non-critical", and, in light of (C) above, also propose that that syntax remove non-critical fields from under the integrity check.