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

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.

Jeffrey