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

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.

Jeffrey