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

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?

-Ekr


> Jeffrey
>