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.
>

Oh, except that section is probably wrong to claim that "a signed response
can improve the privacy situation": the act of validating a certificate
chain could cause the OS to make arbitrary requests to URLs determined by
whoever minted the certificate, so we can't guarantee the authoring origin
is kept ignorant of the client's interest.

Jeffrey