W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Comments on the HTTP Sec-From Header (draft-abarth-origin)

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 31 Jul 2009 12:54:54 -0700
Message-ID: <7789133a0907311254r53e84e81q2570e5acdac023@mail.gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Thanks for your comments.  I've tried to deal with technical changes
in this latest draft.  I'll deal with presentational issues in the
next draft.  For reference, the current version is available here:


On Tue, Jul 14, 2009 at 4:59 PM, =JeffH<Jeff.Hodges@kingsmountain.com> wrote:
> 0. when using term "host" in the spec (e.g. in Sec 2), do you syntactically
> mean <host> from [RFC3986]...
>   host          = IP-literal / IPv4address / reg-name
> ?   (see also comment 6 below)

I believe so.  Please let me know if I've not clarified this
sufficiently in the current draft.

> 1. the spec should have a section defining the sec-from header per se
> (presently it's only introduced in context in Sec 5), and its syntax in ABNF
> [RFC5234]. Here's a quick example of the latter (dunno if exactly correct,
> and depends on syntax decisions you make)...
>   sec-from       = "sec-from" ":" 1*WSP [ "null" / origin-list ]
>   origin-list    = delim-serialized-origin *( 1*WSP delim-serialized-origin
> )
>   delim-serialized-origin = "<" serialized-origin ">"
>   serialized-origin       = scheme "://" host [ ":" port ]
>                           ; <scheme>, <host>, <port> productions from
> RFC3986

Thanks.  I've added this grammar to the draft.  However, I'm unsure
about the serialized-origin production.  Would this sequence of bytes
match that production?

http   ://www.example.com    :     81

If so, we need to revise the grammar to prevent the insertion of extra

> 2. wrt question on list re how to delimit variable names in text -- if you
> use ABNF, then there is IETF precedence for using <rulename> in text (see
> [RFC2616] for example; plus there may be such precedence w/o explicitly
> using ABNF in a spec).

Because this comment is presentational, I've pushed it to the next draft.

> 3. given the ABNF, it may be "easier" to construct a declarative style spec,
> but it wouldn't necessarily rule out algorithmic style (will help make the
> latter more clear imv).

Thanks.  I'll keep this in mind.

> 4. in sections 4 & 5, U+006E, U+0075, U+006C, U+006C ("null") is properly
> not a "character sequence" but a "code point sequence", yes? Thus the actual
> serialized octet sequence for such a sequence (string) will differ depending
> on the actual encoding used, e.g. utf-8 vs utf-16, AFAIK. Also, HTTP header
> fields default to using US-ASCII characters unless the header field value is
> explicitly defined to be of type *TEXT. Thus I suggest that the "null" in
> the <sec-from> production above is sufficient and correct (it is US-ASCII
> encoded per RFC5234), and the U+006E, U+0075, U+006C, U+006C code points
> should be removed from the spec.

I've changed this to say "code point sequence".  I will consider
removing it entirely in the next draft.

> 6. in sections 4.1 & 4.2, the spec references the "IDNA ToUnicode algorithm"
> and the "IDNA ToUnicode algorithm" (both of [RFC3490], which needs to be
> cited, too). This is confusing because the proper reference point in RFC3490
> is Section 4 "Conversion Operations" which contains both of those
> algorithms, as well as specifying steps that need to be taken around
> invocation of either of those algorithms.
> Additionally, RFC3940 is only about DNS domain names, and so the results of
> running <host> values matching the <IP-literal> or <IPv4address> productions
> (RFC3986) through it are undefined AFAIK (I asked Paul Hoffman today and
> that's what he said).
> Here's step 4 of your sec 4.2 re-written to accommodate the above...
>   4.  If the value of the <host> origin tuple component is
>       in the form of a DNS domain name, apply the IDNA conversion
>       algorithm ([RFC3490] section 4) to it, with both the
>       AllowUnassigned and UseSTD3ASCIIRules flags set, employ
>       the ToASCII operation, and append the result to /result/.
> ..though the overall algorithm in draft-abarth-origin may need further
> tweaking wrt running IP addresses thru it.

I believe I have made the modifications you requested.  Please let me
know if this requires further revision.

> 7. Section 5 -- "privacy-sensitive" context is undefined. It is implicitly
> vaguely defined in sec 7. Also, assuming a definition exists, how does some
> given UA "know" whether it is "in" a privacy-sensitive context ?

This will be defined by another specification, presumably at the
application layer.  In the next draft, I'll add some explanatory text.

> 8. We should define exactly what is meant by "an HTTP redirect from URI" foo
> (sec 5). E.g. given foo is the Request-URI in the Request-Line of an HTTP
> message sent to a host:port, then "HTTP redirect from URI foo" is the
> returned HTTP response message from said host:port containing a 3xx Status
> Code (all terms RFC2616).


> 9. In the 2nd Step 2 in Sec 5, where it says "...unless
>       this would result in the header containing the origin
>       serialization "null". "
> Do you mean to say..
>                                               ...unless
>       this would result in the header containing the origin
>       serialization "null" as any component value?
> ?

Done.  I'm unsure what you think the semantic difference is, but
clarifying this point seems beneficial.

> 10. Until I very carefully re-read the algorithm and its immediately
> preceding paragraph in Sec 6, I didn't realize that the "[MUST NOT / MAY]
> modify state" return values _are not_ intended to be sent over the wire to
> the client.
> Could suggest mods, but want to wait until decision is made on whether to
> re-write spec in non-algorithmic style.

I'm not sure how to make this clearer.  No mechanism is given for the
server to communicate the outcome of this algorithm to the client.

> 11. in sec 7 "privacy considerations" this claim is made..
>  "The Sec-From header also improves on the Referer header by NOT
>   leaking intranet host names to external Web sites..."
> ..but isn't it not the "sec-from" header per se that is doing this, rather,
> it's the overall behavior/policy specified by the spec that's providing such
> protection, depending though upon yet-to-be-defined means for determining
> whether any given HTTP request generated by a UA is "in a privacy-sensitive
> context" or is "a privacy-sensitive request" ?

I'm unsure what to do with this text.  It's trying to be helpful by
referring to application layer behavior, but perhaps that's not
appropriate for this spec.

> 12. sec 8 "sec cons" says in part, "This design prevents an attacker from
> making a supporting user agent appear to be a non-supporting user agent."
> But this is only a certain class of attacker, not _any_ attacker (I
> presume). The former being the class that controls some website that issues
> CSRF requests (via whatever means (<form>, .js, etc.)), but otherwise has no
> means to subvert the UA, e.g. turn off sec-from issuance. The latter of
> course relies on correct UA implementation.


> Probably worthwhile to have a "threat analysis" (sub)section along with a
> description of CSRF (as suggested below).

I've pushed this to a future version.

> Editorial comments:

I'll address these comment for the next draft.

Received on Friday, 31 July 2009 19:56:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC