I’ll add another argument for removing the “MUST understand everything” requirement.
JOSE currently uses one bucket (the header JSON object) for different categories of info: 1. Structure of the JOSE message (eg indicate whether the 2nd dot-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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
