Re: Security of cross-origin pushed resources

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.
>>>>>
>>>>
>>>>
>>>
>>
>