On Wed, Jul 25, 2012 at 6:53 PM, Manger, James H < [email protected]> wrote:
> I’ll add another argument for removing the “MUST understand everything” > requirement. > The requirement of understanding everything is only about the layer that performs signature validation, clearly. The header is supposed to be metadata for validation only. Putting non-validation metadata in the header is a bad idea. They payload is arbitrary -- apps can customize it at will to specify app-level metadata semantics there. > **** > > ** ** > > JOSE currently uses one bucket (the header JSON object) for different > categories of info:**** > > **1. **Structure of the JOSE message (eg indicate whether the > 2nddot-separated segment is plain text, an encrypted key, etc) > **** > > **2. **Algorithm details (eg name, IV, etc)**** > > **3. **Hints about keys (eg URI to get key if you don’t have it; > revocation status, etc)**** > > **4. **Metadata about the content (eg content-type, last modified > date, etc)**** > > ** ** > > Even if it is important for security that, say, some structural info is > not ignored that doesn’t mean the same importance applies to the other > categories of info.**** > > ** ** > > Different categories of info will be handled by quite different code. For > instance, a JOSE library is unlikely to care at all about the content > metadata; only the decryption code cares about the IV; etc. To enforce a > “MUST understand everything” requirement all these different pieces of code > from different layers in a software stack (eg app vs library) will need to > cooperate. That cooperation will require more complex APIs between layers > (eg library returns “content”, “headers”, and “list of headers the app MUST > understand because the library ignored them (assuming they are content > metadata)”).**** > > **** > > --**** > > James Manger**** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Brian Campbell > *Sent:* Thursday, 26 July 2012 1:16 AM > > *To:* Manger, James H > *Cc:* Richard L. Barnes; Mike Jones; [email protected] > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > I won't pretend to know what the *right* thing to do is. But I do think > James makes a valid point about the temporal interoperability problems that > will arise if/when new parameters get introduced down the road.**** > > On Sun, Jul 8, 2012 at 6:42 PM, Manger, James H < > [email protected]> wrote:**** > > Mike, > > >> Implementations MUST understand the entire contents of the > >> header; otherwise, the {JWS|JWE} MUST be rejected. > >> > >> We should drop this restriction. > > Mike replied: > > Since this is a security protocol, the way I see it, use of a not- > > understood parameter SHOULD break implementations if they’re not > > prepared to handle them (or at least them cause them to reject the > > input). For example, if we hypothetically added an audience > > restriction parameter, ignoring it would be a security error. (The > > need for audience restriction is being heavily discussed in the OAuth > > WG right now, and real exploits that have occurred for the lack of it, > > so this example is real and fresh on my mind.) If not understood, a > > token containing an audience restriction MUST be rejected. > > > Consider an ecosystem with hundreds of servers and thousands of client > apps all using a protocol involving JOSE messages that has been operating > for a few years. A researcher finds a vulnerability in the protocol and > responsibly discloses it to selected servers. The fix is to add an audience > restriction parameter "aud". > > What should a server do? > > If it adds the "aud" parameter immediately, every (compliant) client app > will immediately break. The outage will last until every app is updated, > which will takes weeks, months…? Total system shutdown to fix a flaw that > is currently theoretical… heads will role. > > If a server announces that it will add the "aud" parameter in, say, 3 > months to give time for app updates then it has just disclosed a > vulnerability and given attackers a 3 month window to exploit it. Many will > clamour for an immediate fix; many will say they need longer to fix apps; > it will still break for many users in 3 months… heads will role. > > On the other hand, if the spec says unknown parameters MUST be ignored > then the server can immediately add the "aud" parameter, and immediately > tell client apps to start supporting it. Each app is protected as soon as > it adds support. > If actual exploits need to be stopped the server can still shutdown the > whole system, or just selected client apps, or selected users. > > > X.509 certificates are an interesting example for comparison. Certs are > security-related, just like JOSE messages. Certs allow unrecognised > additions (eg non-critical extensions). These have been very widely used to > deploy new functionality. > > The X.509 spec (or at least its IETF profile) has one item that MUST be > understood if added: the name-constraints extension. This extension should > be really useful for security. However, because adding it in the > spec-compliant MUST-understand manner will break some clients, it has > barely been deployed for over a decade. > > > Lets drop the "MUST understand everything" requirement. > > -- > James Manger > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > -- --Breno
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
