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

[Richard Barnes <[e-mail]>]

Sorry, John, no agreement on "aad"  :)

If you want integrity checking on non-critical stuff, just put it in the
header and mark it as non-critical.  I'm willing to step back on what I
said in my response to "B"; it can be much more easily mitigated by a
signer putting something random (and not subject-controlled) before the
unknown stuff in the header.



On Mon, Feb 25, 2013 at 5:16 PM, John Bradley <[e-mail]> wrote:

> Karen & Mike,
>
> I think an important issue that Jim and others have tried to get at is
> some information in the header is intended for the JOSE library, while
> other header parameters are essentially additional associated data
> (meta-data about the body) and need to be passed on to other software
> layers for processing along with the body.   ****
> ** **
> An example of that was the proposed "iat" (issued at) element, which needs
> to be processed outside of the JOSE crypto processing to be useful.****
> ** **
> I suspect a point of agreement might be having an "aad" header parameter
> that is a JSON object that MUST be ignored by the JOSE library and passed
> on with the body.  This would provide applications a way to pass meta-data
> through JOSE that is integrity protected, without JOSE having to parse it.
> ****
> ** **
> Once we remove a large number of the possible extension header parameters
> from JOSE processing, the problem gets smaller.****
> ** **
> There is however, still the requirement that extensions for the header
> parameters JOSE processes be possible.****
> ** **
> For that the list of non-critical header parameters is the best solution.
>  That enables a header parameter to be migrated from non-critical to
> critical without changing its JSON element name.****
> ** **
> I think that a large number of people on the list favoured the single
> element with an array of element names that are non-critical.****
> ** **
> My proposal is to add two new top level elements that MUST be understood:*
> ***
> ** **
> 1 "ign":  Ignore - an array of top level elements in the envelope that an
> application MUST ignore if it cannot process them.****
> 2 "aad": Additional Associated Data - a JSON object that MUST be provided
> to applications along with the body if present in a JOSE header.****
> ** **
> All other top level header parameters MUST be understood by a JOSE library
> or produce a processing fault resulting in an error.****
> ** **
> I would also not want elements listed in "ign" to be passed on to
> applications.  I think that would cause interoperability issues.   That is
> what "aad" is intended to provide.****
> ** **
> I know James has legitimate concerns about allowing potentially user
> provided data to be included in the header (Or anywhere likely).  I think
> this is a separate issue that needs to be addressed by security
> considerations to add entropy to the header if such data is included.
> That may require a new "ent" Entropy element that MUST be ignored.  This
> should be a separate discussion.****
> ** **
> Finally, for JWK, I believe that we should just state that not-understand
> elements should be ignored. When including a JWK header parameter this is
> also allows for extension to the JWK parameter, as the MUST understand in
> JWE/JWS only allies to the top level parameter's, and not the sub
> parameters they may contain.****
> ** **
> My proposal doesn't neatly fit into fit into one of the poll answers, but
> I think it may address the majority of concerns.****
> ** **
> Regards****
> John B.
> On 2013-02-25, 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
>
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>