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

On Tue, Jan 30, 2018 at 12:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
> 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.
>
> -Ekr
>
>
So, there are cases where this is good and cases where this is bad.  If I
get data from my bank, I really want to be sure both that the data is from
my bank and that I was the only one that got  it.  If I am getting
information on assisted suicide, I may want to have very strong integrity
protection that the data I got came from a certain provider of that
information, but I may not want network traffic to that provider to be
visible.

I think the main problem here is that the draft appears to describe
critical functions in terms of HTTP 'exchanges':

"These signatures can be verified against an origin’s certificate to
establish that the exchange is authoritative for an origin even if it was
transferred over a connection that isn’t."

That seems to imply that the same set of security properties apply here as
apply to the exchanges which occurr to the origin server.   As RFC 6454
reasons about trust, though, there are requirements not just that the FQDN
be the same, but that the scheme be the same.  Its language on that focuses
on data integrity, but also includes confidentiality:

    Including the scheme in the origin tuple is essential for
   security.  If user agents did not include the scheme, there would be
   no isolation between http://example.com and https://example.com
   because the two have the same host.  However, without this isolation,
   an active network attacker could corrupt content retrieved from
   http://example.com and have that content instruct the user agent to
   compromise the confidentiality and integrity of content retrieved
   from https://example.com, bypassing the protections afforded by TLS
   [RFC5246 <https://tools.ietf.org/html/rfc5246>].

One question we might ask, then, is whether a method which provides
confidentiality to one host and data integrity to another is really the
same "scheme" as one which provides confidentiality and data integrity to
the same provider.  In a standard HTTP proxy, the confidentiality and data
integrity are both guaranteed by the proxy; in an HTTPS connection, they
are both guaranteed by the server.  While this draft's approach seems
better than a standard HTTP proxy in its ability to guarantee data
integrity, the protocol mechanisms don't actually to be the same as either
of those two current choices.  I'm not sure, given that, whether it
actually meets the bar set by RFC 6454.

None of that means that RFC 6454 can't be updated, of course, to cover this
case.  But I think we have to recognize that making this shift probably
requires that.

Ted