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

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.

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

Jeffrey