Subject: [websec] Comments on draft-ietf-websec-origin-00.txt

From: Bill McQuillan <[email-masked]>
Date: Fri, 31 Dec 2010 10:36:26 -0800

Reposting this to the websec list as requested.

My comments on draft-ietf-websec-origin-00.

2.2.  Syntax Notation

The use of <obs-fold> allows for header fields containing lines 
with nothing but spaces and tabs. Does http handle this?

--------------------

4.  Comparing Origins

Although Section 3 discusses an "implementation-defined value" 
and '"sandbox" bits', the comparison algorithm does not mention 
how these are to be handled.

--------------------

5.  Serializing Origins

The "implementation-defined value" and '"sandbox" bits' are not 
discussed in the serialization algorithm.

-----

In step 5 of each algorithm the port is omitted if it is not
"different than the default port". This could be problem since it 
requires three different algorithms to agree on that default.

  1 - At the point where the resource is fetched from the 
      "origin" and the default port MUST be known if the
      correct connection is to be made.
      
  2 - At the serialization point.
  
  3 - At the server receiving the "Origin:" header field.

Instead I recommend that the actual port always be included in 
the serialization to avoid ambiguity. After all it's mainly for 
machine consumption.

--------------------

6.  The HTTP Origin header
6.2.  Semantics

It is not clear what the meaning of multiple origins is. Should 
the client issuing a request include all of the origins that it 
knows about? This might make it more likely that the server 
receiving the request would find an origin it "likes". Or it 
might make it more likely that the server would find an 
objectionable origin. What "meaning" is the client trying to 
communicate to the server?

-----

6.3.  User Agent Requirements

The rule about "two consecutive serialized-origin productions" 
not being identical implies that there is some semantics in the 
ordering of the serialized origins in an Origin header field. 

Also the mention of the way that the "ascii-serialization of the 
origin of previous-uri" is appended to the previous request 
Origin header field implies an ordering.

Does ordering have any semantics in the Origin header field?

-- 
Bill McQuillan <[email-masked]>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 01 Jan 2011 18:42:58 +0100

On 31.12.2010 19:36, Bill McQuillan wrote:
> The use of<obs-fold>  allows for header fields containing lines
> ...

It's supposed to be in sync with what the HTTPbis drafts say, see 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-12.html#rfc.section.3.2>.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sat, 1 Jan 2011 16:25:25 -0800

> with nothing but spaces and tabs. Does http handle this?

What Julian said.

> how these are to be handled.

Sandbox bits are just an example of a way an implementation might
extend an origin value.  There's nothing for this document to say
about them.  An implementation can also extend origins with lettuce,
but that doesn't mean we should explain the procedure for comparing
vegetables.

As for implementation-defined values, they're just that:
implementation defined.  If we defined them in this document, then
they wouldn't be defined by the implementations.

> discussed in the serialization algorithm.

Yes, for the same reasons as above.

>  3 - At the server receiving the "Origin:" header field.

That's correct.

> the serialization to avoid ambiguity. After all it's mainly for

Unfortunately, the various serializations of an origin are already in
wide use throughout the Internet.  It would be prohibitively expensive
to change them in this way.

> It is not clear what the meaning of multiple origins is.

        <t>When included in an HTTP request, the Origin header indicates the
        origin(s) that caused the user agent to issue the request.</t>

If there are multiple origins listed in the header, that means that
they collectively caused the user agent to issue the request.  This is
an Aristotelian notion of causality, not a Lamportian notion.

> Should
> knows about?

No.  The client should follow the instructions in the document.  For
example, the client might know about the origin http://safeway.com,
but most of the time it would be incorrect to include it in the
header.

> This might make it more likely that the server
> objectionable origin.

Indeed.

> What "meaning" is the client trying to

Precisely what the document says:

        <t>When included in an HTTP request, the Origin header indicates the
        origin(s) that caused the user agent to issue the request.</t>

> ordering of the serialized origins in an Origin header field.

I disagree.  It's a syntactic requirement, not a semantic requirement.

> Origin header field implies an ordering.

Yes.  The syntax of the Origin header is indeed ordered.  This is a
consequence of the header field being represented using a sequence of
octets transmitted over a network.

> Does ordering have any semantics in the Origin header field?

Nope.  All the semantic information is described in the section
entitled "Semantics".

Adam