Re: New version of draft-yasskin-http-origin-signed-responses-02

On Tue, Jan 30, 2018 at 3:46 PM Jeffrey Yasskin <jyasskin@google.com> wrote:

> On Tue, Jan 30, 2018 at 2:50 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Tue, Jan 30, 2018 at 2:00 PM, Jeffrey Yasskin <jyasskin@google.com>
>> wrote:
>>
>>> On Tue, Jan 30, 2018 at 1:42 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 30, 2018 at 1:26 PM, Jeffrey Yasskin <jyasskin@google.com>
>>>> wrote:
>>>>
>>>>> On Tue, Jan 30, 2018 at 1:13 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 30, 2018 at 12:35 PM, Jeffrey Yasskin <
>>>>>> jyasskin@google.com> wrote:
>>>>>>
>>>>>>> On Tue, Jan 30, 2018 at 12:18 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 30, 2018 at 11:50 AM, Jana Iyengar <jri@google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm watching from the sidelines, but a clarification question:
>>>>>>>>>
>>>>>>>>> Thanks for taking a look at this. However, I don't think it really
>>>>>>>>>> addresses the concern that I raised, which is not solely about talking to
>>>>>>>>>> the origin but about having a digital signature from the origin server
>>>>>>>>>> substitute for an HTTPS connection to the origin.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In the current world, client does DNS lookup, establishes a TCP
>>>>>>>>> connection, creates a secure channel to an authenticated origin, and gets
>>>>>>>>> content from it over this channel.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>
>>>>>>>> Per my understanding, the proposal here basically removes the DNS
>>>>>>>>> lookup + TCP connection to the origin, but creates a secure channel to an
>>>>>>>>> authenticated proxy, and separately authenticates content that it gets from
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well, the proxy is largely irrelevant here, as the client has no
>>>>>>>> particular relationship with it. From a security perspective, the client
>>>>>>>> gets some content from a random location and trusts it because it's
>>>>>>>> digitally signed by the origin server.
>>>>>>>>
>>>>>>>>
>>>>>>>> The client would previously have authenticated the channel to the
>>>>>>>>> origin and gotten any content from it. In this proposal, a client does a
>>>>>>>>> TLS handshake to secure the channel to the proxy, and then authenticates
>>>>>>>>> content that comes over it. Is this understanding correct? If so, it
>>>>>>>>> *seems* equivalent security to HTTPS.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think that's true. At *most* it provided data origin
>>>>>>>> authentication/integrity (feel free to argue non-repudiation, but that's
>>>>>>>> not really relevant here). It doesn't provide confidentiality to the origin
>>>>>>>> server at all.
>>>>>>>>
>>>>>>>
>>>>>>> Exactly, it's confidentiality to the physical server (given the
>>>>>>> recently-added privacy guidance to restrict package fetches to TLS) but not
>>>>>>> to the origin server.
>>>>>>> https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-02#section-7
>>>>>>> explains why that's not quite as bad as for a "random" location, but it's
>>>>>>> still a different guarantee than the lock icon usually claims.
>>>>>>>
>>>>>>
>>>>>> Rather then nitpicking "random location".... It seems like the
>>>>>> situation is that if o2.com has produced a signed package than
>>>>>> anyone with a TLS certificate who can get you to connect to them can
>>>>>> present you content with origin o2.com, no?
>>>>>>
>>>>>
>>>>> Yes, if you follow a link, whoever presented the link can know you
>>>>> followed it (either via javascript or via a 302 redirect), and the link can
>>>>> result in content from o2.com. signed-exchanges change whether
>>>>> there's a physical connection to o2.com, but that physical connection
>>>>> isn't user-visible in any case.
>>>>>
>>>>
>>>> I'm not sure what you mean by "not user-visible". That's the semantic
>>>> that we currently have that this proposal breaks.
>>>>
>>>
>>> How does the user know which physical connections were made? If I see
>>> o2.com in my URL bar, that might mean that my browser made a connection
>>> to o2.com, or that it served something out of the cache without making
>>> any connections.
>>>
>>
>> What it definitely knows is that you didn't connect to some other random
>> server.
>>
>>
>> More importantly, is it a violation of confidentiality for *fewer*
>>> entities to be told that I'm visiting a resource?
>>>
>> (With the caveat that a certificate could be crafted that leads to the
>>> same number of entities being told.)
>>>
>>
>> The confidentiality issue is that the data that was sent to the client
>> was protected in transit, not shared with some random third party.
>>
>
> Clearly we're not communicating well, so I'm going to take a night to
> sleep on it and try to compose clearer questions. Thanks for taking the
> time to reply so far.
>

So, I start with a presumption that the confidentiality guarantee of TLS is
there to ensure some higher-level properties that humans care about. For
example, if Asha fetches a bank page, she doesn't want anyone but her bank
and her to learn her balance. If Davu fetches a social network page, he
doesn't want anyone but the network and himself to know the authentication
cookies that prove he's him. If Lupita fetches a page of medical
information, she'd prefer that *nobody* know she fetched it, but she'll
accept the author of the page finding out.

Now, say inter.com offers a collection of signed exchanges that folks can
download instead of talking to the exchanges' original authors. inter.com
can't offer Asha's or Davu's page because it can't authenticate to the bank
or social network to get those pages. inter.com can offer Lupita's page,
but how does she wind up fetching the https://inter.com/lupitas-page URL
instead of the https://medical.com/lupitas-page that it originally came
from? If she clicks a link written as <a href="
https://medical.com/lupitas-page">, she doesn't: she connects to the
original origin. Unlike some previous schemes I've heard of, there's no
attempt to auto-discover proxies or caches.

If she instead clicks a link written as <a href="https://
inter.com/lupitas-page">, she connects to inter.com. Today, inter.com might
record her visit and then use a 302 redirect to send her on to
https://medical.com/lupitas-page. She sees https://medical.com/lupitas-page
in her URL bar, and doesn't realize that she was forwarded through "some
other random server". That's today, with no changes. TLS's confidentiality
model did not prevent inter.com from learning about her visit.

What if Lupita's browsing https://inter.com/directory and sees a link to <a
href="https://medical.com/lupitas-page">? She's being careful and checks
her status bar before clicking, but, whoops, inter.com had attached an
event listener to the link, which either calls sendBeacon("https://
inter.com/visited-lupitas-page") or sets location.href to https://
inter.com/lupitas-page, and again tells inter.com about the visit.

If we implement signed-exchanges, https://inter.com/lupitas-page can host
the content directly. Lupita clicks the link to https://
inter.com/lupitas-page, sees her URL bar change to
https://medical.com/lupitas-page, and sees the content from medical.com.
The same people find out about her click: inter.com and medical.com, except
that it's possible medical.com doesn't even find out.

So, what practical effect did the change to signed exchanges have? There
must be an aspect to the story that I've missed--you have much more
experience here and wouldn't be worried over nothing--and I'd greatly
appreciate hearing it.

Thanks,
Jeffrey