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

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.

-Ekr


>
> Jeffrey
>