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

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.

Jeffrey