Subject: [tram] Review of origin draft

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Aug 2014 11:48:19 -0700

I've read this through and have some comments:

Definition of origin:
This document uses a more expansive definition than the one in RFC
6454.  While it appears that this is consistent, I think that this
needs to be made more prominently.

And given that RFC 6454 is a relatively large document (20 pages), I'm
a little concerned that the definition for SIP and XMPP origins is a
little lean.  At a minimum, I think that you need to identify what
components from the respective BNF definitions of XMPP and SIP URIs
are kept and what are removed.

Multiple origins:
I'm not sure that you really need to concern yourself with multiple
origins.  The ability to carry multiple Origin header fields in HTTP
is bound to the way that browsers fetch resources.  This can sometimes
mean that a resource is fetched by multiple origins (tabs, frames,
windows, etc...) at the same time.  Even then, it is relatively rare
that this will happen.

In the context of WebRTC, I can't think of a single case where origin
will need to be doubled.  Any single binding request will be at the
behest of a single origin; and while a TURN allocation might be shared
between multiple origins, that will only happen because it's the
browser acting on its own writ, not on behalf on any origin.
Individual channels might need an origin binding in that case.

In the other contexts, it seems obvious that similar constraints apply.

Privacy:
The privacy section talks about protection in transit, but does not
talk about the ability of a STUN or TURN server itself to learn about
communication usage, something it would not normally be able to
obtain.  Some text on this would be useful, since these parties were
previously either entirely supplemental to communication, or only
involved in the peer-to-peer communications.  I'm sure that this
information could be turned into money, so there has to be at least
some privacy implications there.

Size:
The recommended limit on size is a little odd.  It should be
impossible to generate an origin that exceeds this number.  I would
leave the advice at the point were the maximum size is noted and the
potential this has to cause fragmentation.

TLS SNI:
I found the introduction to be a little long and wordy, perhaps
excessively justified.  The discussion of SNI might be appropriate for
convincing the working group of the need for this solution over
something based on SNI, I found this both completely obvious (of
course SNI doesn't work) and actually somewhat non-sequitur.  I think
that this paragraph (at least) could be removed.

Redundant text:
   To ensure backwards compatibility with [RFC3489], the ORIGIN
   attribute is padded to ensure its length is a multiple of 4 octets.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 21 Aug 2014 13:41:37 -0500

Martin,

Thanks for doing this review.  My comments are below.  Hopefully others
will also weigh in on the issues you raise.

- Alan -

> needs to be made more prominently.
That is a very good point to be made in the introduction and perhaps even
the abstract.

> are kept and what are removed.

Right.  The XMPP does mention parts of the ABNF and gives an example.  We
should add the same for SIP.

> Individual channels might need an origin binding in that case.

Interesting - I had thought, incorrectly it seems, that if a page from one
domain fetched a script from another domain that accessed a resource, that
the HTTP origin would include both domains.  The case of a resource fetched
at the same time by multiple origins doesn't seem to apply to WebRTC.  Each
of these origins would correspond to a different Peer Connection.  I don't
think a browser would ever share STUN bindings or TURN allocations across
different Peer Connections.  If we can rule out this behavior, then perhaps
the text on multiple origins can just say that it can't happen.

> In the other contexts, it seems obvious that similar constraints apply.
Since we are defining it for SIP and XMPP, we can just make it a MUST NOT.

> some privacy implications there.

That is a good point.  For a STUN server, this is new information, not
otherwise available.  For a TURN server, if realm doesn't map 1:1 to
origin, then this also provides new information.  I will propose some text
on this.

> potential this has to cause fragmentation.
If we can do away with multiple origins, then I'm fine with this.

> that this paragraph (at least) could be removed.

I hadn't read the Introduction in a while, and I agree.  I can write a much
better introduction.

>    attribute is padded to ensure its length is a multiple of 4 octets.

Since this is already a MUST in RFC 5389, this is redundant and can be
removed.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Aug 2014 12:48:37 -0700

On 21 August 2014 11:41, Alan Johnston <[email-masked]> wrote:
> the HTTP origin would include both domains.

The Origin: header field is populated by the entity that initiates the
fetch.  Typically, that's the origin in the address bar.  Where the
script that is being run was retrieved from doesn't matter.  (e.g., a
page can import jquery, but it runs code under its own domain, not
jquery's).

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Aug 2014 22:09:40 -0700

> the text on multiple origins can just say that it can't happen.

Yes, I think this would never happen; each PC has its own state, and
sharing this state across origins would be problematic, to say the least.

> origin, then this also provides new information.  I will propose some text

Note that this is in many ways similar to the SOFTWARE attribute, which in
the pre-WebRTC days provided similar information about usage. Of course, in
the WebRTC case, the TURN server will be specified by the application, so
the application at least knows who will have access to this data.

> I hadn't read the Introduction in a while, and I agree.  I can write a
> much better introduction.
>
>
>>
>> Redundant text:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Aug 2014 11:04:24 -0700

On 21 August 2014 22:09, Justin Uberti <[email-masked]> wrote:
> Of course, in the WebRTC case, the TURN server will be specified by the
> application, so the application at least knows who will have access to this
> data.

That's only true if we don't have browser-configured STUN servers (or
even TURN servers, as unlikely as that seems).

Obviously, if the browser configures a STUN server, then they might
want to take some precautions here, but that doesn't remove the
privacy considerations.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Aug 2014 16:57:36 -0700

Agreed.