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

[Tim Bray <[e-mail]>]

One addition to Mike’s notes.  If you are going to have ignorable fields,
it’d be nice to avoid one of the (many, many) design botches that increased
the difficulty of doing SOAP; it had a thing where you could specify, in
among the SOAP headers, a MUST-UNDERSTAND rule. The effect was that you
didn’t know whether you could act on any header until you’d seen them all,
because there might be a MUST-UNDERSTAND lurking somewhere.

The "ign" : [ "notes" ] idiom has, to my eye, that drawback.  The
structured one lets you know, as soon as you see a field, whether it’s OK
to not understand it.  -T


On Mon, Feb 25, 2013 at 7:41 AM, Mike Jones <[e-mail]>wrote:

>  Thanks for sending this, Karen.  Hopefully your analysis will help the
> working group reach a resolution on this issue soon.  I’m writing this note
> primarily as an editor to help inform the working group’s discussions,
> rather than as an individual contributor.****
>
> ** **
>
> First, I want to point out that while we’ve been discussing criticality of
> header parameters, the specs actually currently have the “MUST be
> understood” language in the JWK specification as well, as that’s another
> potential extension point.  The JWK description says “Additional members
> MAY be present in the JWK.  If present, they MUST be understood by
> implementations using them.”  The same language is present for the JWK Set.
>  For our resolution of the issue to be complete, it should address those
> uses too.  Given that a number of additional JWK fields are being
> discussed, I expect that extensions will occur there.****
>
> ** **
>
> Second, if we do decide to go with your approach (1), I’ll summarize for
> the list what I believe the two syntax proposals on the table are for doing
> this.  One proposal is 2A in
> http://www.ietf.org/mail-archive/web/jose/current/msg01353.html (which
> I’ll call the FLAT SYNTAX) and the other is the syntax that Dick Hardt
> proposed in
> http://www.ietf.org/mail-archive/web/jose/current/msg01457.html (which
> I’ll call the STRUCTURED SYNTAX).  I believe that it would be useful for
> the working group to discuss which of those they would prefer in parallel
> to discussing the questions that you asked, so that if we do go with
> approach (1) or something like it, we’ll know which to use.****
>
> ** **
>
> FLAT SYNTAX:****
>
>     {"alg":"ES256",****
>
>      "ign":["notes"],****
>
>      "notes":"This header field can be safely ignored"****
>
>     }****
>
> ** **
>
> STRUCTURED SYNTAX:****
>
>     {"alg":"ES256",****
>
>      "ign":{****
>
>        "notes":"This header field can be safely ignored"****
>
>       }****
>
>     }****
>
> ** **
>
> As I see it, the advantage of the flat syntax is all header fields are in
> the same place.  This makes processing header fields easier and is more
> regular.  The disadvantage is that the list of fields that may be safely
> ignored repeats those field names.****
>
> ** **
>
> As I see it, the advantage of the structured syntax is that nothing is
> repeated, resulting in cleaner JSON syntax.  The disadvantage is that then
> some header fields are in one place and some are in another, making the
> processing rules for header fields more complicated.****
>
> ** **
>
> Between these two, it seems to come down to a choice between cleaner
> syntax or cleaner semantics.  (I’d personally lean towards the simpler
> processing rules resulting from the flat syntax, but I would be fine with
> this coming out either way.)****
>
> ** **
>
> Finally, I’ll point out that I don’t believe that your approaches (1) and
> (2) are mutually exclusive.  We could conceivably leave it up to
> application specifications using the JOSE specs whether they require header
> fields to be understood by default AND provide a syntax for declaring which
> fields may be safely ignored for use in those application contexts where
> the application spec does require that header fields be normally
> understood.  In fact, one might consider this to fall under the “(possibly
> providing guidance directed to those applications in the JOSE specs)”
> that you suggested below.****
>
> ** **
>
> I hope the points above help further a productive discussion of this topic.
> ****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Karen O'Donoghue
> *Sent:* Monday, February 25, 2013 3:26 AM
> *To:* [e-mail]
> *Subject:* [jose] thoughts on header criticality from recent polls****
>
> ** **
>
> Folks,
>
> Thank you for your patience with me regarding the recent polls on header
> criticality. I realize I have taken too long to respond from a chairs
> perspective with some results and direction. I had hoped to provide either
> a decision or a clear set of choices, but after analyzing the poll results,
> rereading all the email traffic (multiple times), and talking to a few
> working group members, I find I am not quite able to do so. So, what
> next...
>
> First, what I do believe...
>
> I think it is clear that the working group remains divided on this issue
> with a significant number of members feeling that an approach must be
> defined that safely allows for some header fields to be considered
> non-critical. I think there is general consensus that there must be
> reasonable mechanisms for extensibility, and that the approach must be
> generic. Based on that, I would like to ask the working group to move
> forward with the strategy that all headers cannot be considered critical
> and move on to the discussion of how to approach non-critical headers.
>
> In my review of the mailing list traffic (and my apologies if I missed
> something), I have seen a number of basic approaches proposed (summarized
> by Jim Schaad on 9 Oct 2012 with the response by James Manager on 10 Oct
> 2012). In particular, I found James' list of requirements to be very
> helpful, and I have repeated it here...
>
> 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.
>
> 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.
>
> QUESTION: Can the working group agree on whether to work on approach 1 or
> approach 2?
>
> In conclusion, I am asking three things in this missive:
> 1. I am asking the working group to move forward based on a non-critical
> headers approach.
> 2. I am asking the working group to clarify the requirements driving the
> non-critical header discussion (A, B, C, D, E, or ?).
> 3. I am asking the working group to decide whether the right approach is
> to develop a specific syntax (if so, what?) or to defer to the applications
> with appropriate guidance (if so, what level of guidance)? To address this
> item, I welcome concise proposals of text.
>
> I realize this message is long and not as specific or prescriptive as some
> would like, and I apologize in advance for any mistakes and
> misunderstandings on my part.
>
> Regards,
> Karen O'Donoghue****
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>