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

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.

-Ekr


>
> Jeffrey
>