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

On Tue, Jan 30, 2018 at 1:31 PM Ted Hardie <ted.ietf@gmail.com> wrote:

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

Hi Ted,

That's an interesting point, thanks. When framed in the context of RFC6454
(Web Origins), I think you're asking whether it makes sense for a resource
received via a signed exchange to be able to script a resource received
over simple TLS, and vice versa.

Your example of a bank is instructive: they might sign a set of exchanges
representing the banking application, and allow that to be forwarded by
anyone (
https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-00#section-2.1.1),
but require direct authenticated connections for a person's actual banking
information. If the application's script can't access the banking
information, that's not so useful. I also don't see any attacks this makes
possible. Do you?

----

We might also frame the question about the definition of the https: scheme (
https://tools.ietf.org/html/rfc7230#section-2.7.2) rather than origins.
That says:

"the user agent MUST ensure that its connection to the origin server is
> secured through the use of strong encryption, end-to-end, prior to sending
> the first HTTP request."


That probably needs updating regardless:
1. It restricts the connection to the origin server without requiring that
such a connection must exist.
2. It doesn't clearly forbid or allow loading an https: resource from a
cross-origin PUSH or the application/http-exchange+cbor format
<https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html#rfc.section.5>:
those routes merely populate the cache, and then the resource is loaded
without sending any further HTTP requests.
3. There's another proposal that I haven't written up yet, which could
allow a server to send an HTTP/2 frame advertising a set of cross-origin
signed exchanges. Then the client could request those resources over that
connection instead of making a new connection to their origin servers.
That's more nearly banned by RFC7230, which should either actually ban it
or clearly allow it. (It may also have severe privacy problems; I haven't
thought it all the way through.)

There's also a UI question about whether seeing "https:" indicates to users
that they have certain confidentiality properties. I think that's covered
by my discussion with Ekr, where I'm claiming that users have the same
guarantees after signed-exchanges as they had before.

Thanks,
Jeffrey