Subject: [jose] Criticality of Headers - Possible Answers

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Oct 2012 11:27:35 -0700

I am looking to establish the possible answers that we have for criticality
of header fields and then want to follow it up with a discussion hopefully
leading to closure.

Please respond if I am missing any of the different solutions or if you
think that I have all of the solutions that were discussed for the options.
Also please feel free to augment the wording I have below on the description
of the solution.  I want to deal with pros and cons after we have the
descriptions agreed on.

1.  Any headers not covered by the current document generate an error.  This
is the current state of the document and is the all headers are critical
solution.

2.  Any headers not covered by the current document are ignored.  This is
the no headers are critical solution.

3.  Headers are to be decorated in some manner to say if they are critical.
There are four possible decoration methods that I have seen proposed.

a)  Change the field name to indicate it is critical (ala "SignTime!")
b)  Change the field name to indicate it can be ignored (ala "SignTime?")
c)   Create a header that has a list of either critical (or ignorable) field
names
d)  Separate the non-critical header fields into a sub header

4.  The core specification should ignore all issues of criticality and just
define a common set of headers.  It is up to the application to define which
headers are critical, which can be ignored, and it can define new headers to
meet it's needs.

Jim

---

From: Mike Jones <[email-masked]>
Date: Tue, 9 Oct 2012 18:49:35 +0000

I believe that the poll established that the working group affirmed the current semantics by a substantial margin, effectively closing this issue.  Karen, can you please make a consensus call based upon the poll results?

Thank you,
-- Mike

________________________________
From: Jim Schaad
Sent: 10/9/2012 11:29 AM
To: [email-masked]
Subject: [jose] Criticality of Headers - Possible Answers

Jim

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 11 Oct 2012 10:58:39 +1100

Jim,

Another possible solution:

5. One primary field is critical to understand.
   [Ideally a field identifying the type of protection:
   MACed, dig.sig., sym.encrypted, plain...]
   The specification of each value of the primary
   field indicates which other fields are critical
   to understand when that primary value is present.

More important than these 5 syntaxes for indicating criticality, however, is agreeing on what we are trying to achieve with criticality. I don’t think the current drafts provide any clue.

Possible requirements for making things critical:

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; KISS principle; version 1.0 is vastly more important that any subsequent version.

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.

F. ...

The MUST-understand-everything rule feels appropriate for E, maybe for D, doesn't achieve C, and is (harmfully) far more draconian than necessary for B or A.
I think JOSE should aim for requirement A.

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jim Schaad
> Sent: Wednesday, 10 October 2012 5:28 AM
> To: [email-masked]

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 10 Oct 2012 17:11:46 -0700

James,

I think that is an interesting set of reasons.  I would add the following to the list

F.  Application developers and specification writes are unable to correct assess what is and is not important from the point of view of security.  It is therefore better that the signature header fields are fully defined independent of any possible application specifications.

While I disagree (in part) with the above statement for a number of reasons, I believe that there are number of people who would believe that it is a true statement.  I agree that application developers and specification writers don't understand all of the implications, but I believe we can provide good guidance to them as part of this specficiation.

Jim

> From: Manger, James H [mailto:[email-masked]]
> Sent: Wednesday, October 10, 2012 4:59 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: [jose] Criticality of Headers - Possible Answers
> 
> Jim,
> 
> More important than these 5 syntaxes for indicating criticality, however, is
> agreeing on what we are trying to achieve with criticality. I don t think the
> current drafts provide any clue.
> 
> 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; KISS principle; version 1.0 is vastly more
> important that any subsequent version.
> 
> 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.
> 
> F. ...
> 
> 
> The MUST-understand-everything rule feels appropriate for E, maybe for D,
> doesn't achieve C, and is (harmfully) far more draconian than necessary for B
> or A.
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Jim Schaad
> > I am looking to establish the possible answers that we have for
> > criticality of header fields and then want to follow it up with a
> > discussion hopefully leading to closure.
> >
> > Please respond if I am missing any of the different solutions or if
> > you think that I have all of the solutions that were discussed for the
> > options.
> > Also please feel free to augment the wording I have below on the
> > description of the solution.  I want to deal with pros and cons after
> > we have the descriptions agreed on.
> >
> > is the current state of the document and is the all headers are
> > critical solution.
> >
> > 2.  Any headers not covered by the current document are ignored.  This
> > is the no headers are critical solution.
> >
> > 4.  The core specification should ignore all issues of criticality and
> > just define a common set of headers.  It is up to the application to
> > define which headers are critical, which can be ignored, and it can
> > define new headers to meet it's needs.
> >
> > Jim
> >
> >