Re: [XHR2] Feedback on sec-* headers
On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: > On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes wrote: >> Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing >> the headers that are secure (I'll assume the enumeration stays, though it >> doesn't necessarily have to). Any header name that is contained either in >> the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's >> insecure. This allows any header to be marked as secure, regardless of its >> name. >> >> It's also arguably easier to implement: >> 1. On the sending side: >> 1.curr. Check membership in a fixed enum || prefix >> 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen >> enum) >> 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum >> 2. On the receiving side: >> 2.curr. Check membership in a fixed enum || prefix >> 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed >> enum >> >> The major concern is backward compatibility. I don't really know what the >> state of the art is on the use of Sec-* headers, so I can't comment much on >> practical concerns. But you could accommodate this to some extent with some >> wildcarding in the XHR2-Secure header and a recommendation to include Sec-* >> in the UA-chosen enum. > > Would this not mean that for each new header introduced servers would have to > check an "XHR2-secure" header in addition to it to make sure it is not being > spoofed? That kind of complexity seems like something we should avoid. Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. --Richard
[XHR2] Feedback on sec-* headers
Jumping over to this list (hi, I'm new here!) from another list. To recap: I had chimed in in support of Mark's proposal, and Anne said "It fails to meet the goal of Sec-", with a pointer to this thread. It seems like the high-level requirement is for the recipient of an HTTP request to know which parts of the request are "secure", in the sense that they were set by the UA, and which are "insecure", in the sense that they are, or may have been, set by a script. Presumably the entity-body is always insecure, so we're confined to header fields. The current XHR and XHR2 specs satisfy this requirement by means of an enumeration of headers plus a prefix. Any header name in the enumeration, or starting with the prefix, is secure, otherwise it's insecure. As Mark noted, this deals poorly with extensibility, since any new secure headers have to go in the "Sec-*" prefix. This is especially problematic if a UA wants to protect some standard field beyond the enumeration (say, X-Forwarded-For), or if there is some other convention that calls for a different prefix. Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to). Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure. This allows any header to be marked as secure, regardless of its name. It's also arguably easier to implement: 1. On the sending side: 1.curr. Check membership in a fixed enum || prefix 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum) 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum 2. On the receiving side: 2.curr. Check membership in a fixed enum || prefix 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum The major concern is backward compatibility. I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns. But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum. --Richard
Re: [XHR2] Feedback on sec-* headers
[sorry if this is a repeat, sent first copy in the process of joining the list] Jumping over to this list (hi, I'm new here!) from another list. To recap: I had chimed in in support of Mark's proposal, and Anne said "It fails to meet the goal of Sec-", with a pointer to this thread. It seems like the high-level requirement is for the recipient of an HTTP request to know which parts of the request are "secure", in the sense that they were set by the UA, and which are "insecure", in the sense that they are, or may have been, set by a script. Presumably the entity-body is always insecure, so we're confined to header fields. The current XHR and XHR2 specs satisfy this requirement by means of an enumeration of headers plus a prefix. Any header name in the enumeration, or starting with the prefix, is secure, otherwise it's insecure. As Mark noted, this deals poorly with extensibility, since any new secure headers have to go in the "Sec-*" prefix. This is especially problematic if a UA wants to protect some standard field beyond the enumeration (say, X-Forwarded-For), or if there is some other convention that calls for a different prefix. Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to). Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure. This allows any header to be marked as secure, regardless of its name. It's also arguably easier to implement: 1. On the sending side: 1.curr. Check membership in a fixed enum || prefix 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum) 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum 2. On the receiving side: 2.curr. Check membership in a fixed enum || prefix 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum The major concern is backward compatibility. I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns. But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum. --Richard
