Re: Security of cross-origin pushed resources

This looks good to me, or at least is the right direction.
-=R


On Sat, Sep 21, 2013 at 8:42 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> maybe less is more in this case?
>
>
> 10.1 <http://http2.github.io/http2-spec/#rfc.section.10.1> Server
> Authority and Same-Origin
>
> This specification uses the same-origin policy ([RFC6454]<http://http2.github.io/http2-spec/#RFC6454>,
> Section 3 <http://tools.ietf.org/html/rfc6454#section-3>) to determine
> whether an origin server is authorized to provide content.
>
> The resource origin SHOULD be considered to match the server if the
> connection can authenticate the domain part of the resource origin with a
> TLS certificate used on that connection. Connections to origin servers
> without TLS authentication MUST use a single origin.
>
> A client MUST NOT use, in any way, resources provided by a server that is
> not authoritative for those resources.
>
>
>
>
>
> On Fri, Sep 20, 2013 at 9:21 PM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> As usual, I feel like when you and I disagree on mailing lists, we spend
>> many roundtrips just to find out that we misunderstood each other and we
>> actually agree :)
>>
>> So, when I said "I'm supportive of changing the spec to remove
>> cross-origin push for http URIs." I meant http:// scheme, and primarily
>> I meant unauthenticated (I know that Patrick is hopeful we can authenticate
>> and encrypt http:// URIs in the future, but when I say http:// scheme
>> today, I mean unauthenticated). So no cert or anything.
>>
>> Does that clear it up? If not, then I think I don't understand or just
>> actually disagree :P Do you think we need to change the existing text, and
>> if so, what do you propose?
>>
>> http://http2.github.io/http2-spec/#rfc.section.10.1
>> =====
>> A server that is contacted using TLS is authenticated based on the
>> certificate that it offers in the TLS handshake (see [RFC2818], Section 3).
>> A server is considered authoritative for an "https" resource if it has been
>> successfully authenticated for the domain part of the origin of the
>> resource that it is providing.
>>
>> A server is considered authoritative for an "http" resource if the
>> connection is established to a resolved IP address for the domain in the
>> origin of the resource.
>>
>> A client MUST NOT use, in any way, resources provided by a server that is
>> not authoritative for those resources.
>> =====
>>
>>
>> On Fri, Sep 20, 2013 at 8:46 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>
>>> No, the domain is authenticated, as per the cert. HTTP-level
>>> authentication is different.
>>> -=R
>>>
>>>
>>> On Fri, Sep 20, 2013 at 8:13 PM, William Chan (陈智昌) <
>>> willchan@chromium.org> wrote:
>>>
>>>> I think you're not stating some context. Are you assuming some form of
>>>> authentication for http URIs?
>>>>
>>>>
>>>> On Fri, Sep 20, 2013 at 7:53 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>>>
>>>>> Wait a sec, that isn't what I'm saying..
>>>>>
>>>>> I'm saying, regardless of scheme, that no element should be
>>>>> interpreted as a result of a push for an origin unless that origin has been
>>>>> authenticated.
>>>>> Of course, there are other requirements for HTTPS about
>>>>> authentication, which make this statement less interesting for HTTPS, but
>>>>> it is interesting for HTTP...
>>>>>
>>>>> -=R
>>>>>
>>>>>
>>>>> On Fri, Sep 20, 2013 at 5:59 PM, William Chan (陈智昌) <
>>>>> willchan@chromium.org> wrote:
>>>>>
>>>>>> All very convincing points. I'm supportive of changing the spec to
>>>>>> remove cross-origin push for http URIs.
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 20, 2013 at 1:08 PM, Patrick McManus <
>>>>>> pmcmanus@mozilla.com> wrote:
>>>>>>
>>>>>>> I think Jo has a reasonable point. Cross origin pushes that can have
>>>>>>> their domain be backed up by a verifiable cert are pretty awesome, but
>>>>>>> lacking that we shouldn't allow them in an unverified context.
>>>>>>>
>>>>>>> no matter what we do in specification land, people are going to put
>>>>>>> L4 load balancers in front of two nodes that aren't really related to each
>>>>>>> other (an issue the cert can sort out) and this becomes a pretty easy
>>>>>>> exploit. We would essentially be changing the definition of origin from
>>>>>>> hostname to be resolved-ip and I don't think that's in our purview to do.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 20, 2013 at 3:26 PM, William Chan (陈智昌) <
>>>>>>> willchan@chromium.org> wrote:
>>>>>>>
>>>>>>>> I think this is a good question that I don't know is well specified
>>>>>>>> anywhere. I recall us discussing for HTTP/1.1 whether or not it's feasible
>>>>>>>> for a client to reuse a TCP connection for the same destination IP address,
>>>>>>>> even if it's for different origins. My understanding is mnot ran a quick
>>>>>>>> test of the feasibility and showed that it works 99.X% of the time or
>>>>>>>> something, but my memory's vague on the matter. Mark can correct me here.
>>>>>>>>
>>>>>>>>
>>>>>>> I've done the research on this in the past - but the details are
>>>>>>> fuzzy. There was a prominent LB that had a switch through mode that was a
>>>>>>> recommended performance best practice.. basically after finding the first
>>>>>>> request (cookies and host header primarily) it determined what back end to
>>>>>>> use and from there just went into a TCP tunnel thereafter. So there were
>>>>>>> definite security issues and interop argument along the lines of "it works
>>>>>>> for N nines" probably isn't enough.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>