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

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 29 Jan 2018 16:56:57 +0000

I've updated my signed-exchanges draft that was previously discussed at
https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0396.html.

A list of significant changes is at
https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html#change-log
.

Please look at the sections titled "Open Questions" and propose some
answers. :)

What kinds of changes and/or reviews do you want before adopting this as a
WG draft, perhaps at IETF101?

The one negative comment I've gotten is from Ekr, who wants clients to make
a TLS connection to the true origin (or, via the CERTIFICATE frame, to
anyone who's been issued a fake certificate) to validate the exchange. To
attempt to address this, the draft now insists that the signature's
"validityUrl" be same-origin with the claimed request URI, and
https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html#seccons-downgrades
suggests that clients can fetch that URL more eagerly than just when the
signature expires.

We have an implementation in progress in Chromium:
https://groups.google.com/a/chromium.org/d/topic/blink-dev/n7cZXSTwBTY/discussion
.

Thanks,
Jeffrey

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jan 2018 05:38:25 -0800

On Mon, Jan 29, 2018 at 8:56 AM, Jeffrey Yasskin <[email-masked]>
wrote:

> A list of significant changes is at https://tools.ietf.org/id/
> draft-yasskin-http-origin-signed-responses-02.html#change-log.
>

I think adoption here is premature. This is a pretty major architectural
deviation from the current model and it's not clear to me that its well
motivated by the use cases for which there is (even rough) consensus.

> https://tools.ietf.org/id/draft-yasskin-http-origin-
> signed-responses-02.html#seccons-downgrades suggests that clients can
> fetch that URL more eagerly than just when the signature expires.
>

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.

-Ekr

> We have an implementation in progress in Chromium: https://groups.
> google.com/a/chromium.org/d/topic/blink-dev/n7cZXSTwBTY/discussion.
>
> Thanks,
> Jeffrey
>

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 30 Jan 2018 11:50:03 -0800

I'm watching from the sidelines, but a clarification question:

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

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.

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jan 2018 12:17:37 -0800

On Tue, Jan 30, 2018 at 11:50 AM, Jana Iyengar <[email-masked]> wrote:

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

> authenticated proxy, and separately authenticates content that it gets from

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.

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

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 30 Jan 2018 20:35:27 +0000

On Tue, Jan 30, 2018 at 12:18 PM Eric Rescorla <[email-masked]> wrote:

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

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

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 30 Jan 2018 20:44:07 +0000

On Tue, Jan 30, 2018 at 12:35 PM Jeffrey Yasskin <[email-masked]>
wrote:

>> Per my understanding, the proposal here basically removes the DNS lookup
>>> + TCP connection to the origin, but creates a secure channel to an

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jan 2018 13:12:26 -0800

On Tue, Jan 30, 2018 at 12:35 PM, Jeffrey Yasskin <[email-masked]>
wrote:

> 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

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 30 Jan 2018 21:26:14 +0000

On Tue, Jan 30, 2018 at 1:13 PM Eric Rescorla <[email-masked]> wrote:

> 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

Yes, if you follow a link, whoever presented the link can know you followed
it (either via javascript or via a 302 redirect), and the link can result
in content from o2.com. signed-exchanges change whether there's a physical
connection to o2.com, but that physical connection isn't user-visible in
any case.

Jeffrey

---

From: Ted Hardie <[email-masked]>
Date: Tue, 30 Jan 2018 13:31:02 -0800

> not really relevant here). It doesn't provide confidentiality to the origin
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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jan 2018 13:41:45 -0800

On Tue, Jan 30, 2018 at 1:26 PM, Jeffrey Yasskin <[email-masked]>
wrote:

>>>> Per my understanding, the proposal here basically removes the DNS
>>>>> lookup + TCP connection to the origin, but creates a secure channel to an
>>>> 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
>>> 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.
>>>
>>
> Yes, if you follow a link, whoever presented the link can know you
> followed it (either via javascript or via a 302 redirect), and the link can
> result in content from o2.com. signed-exchanges change whether there's a
> physical connection to o2.com, but that physical connection isn't
> user-visible in any case.
>

I'm not sure what you mean by "not user-visible". That's the semantic that
we currently have that this proposal breaks.

-Ekr

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 30 Jan 2018 22:00:56 +0000

> we currently have that this proposal breaks.

How does the user know which physical connections were made? If I see o2.com
in my URL bar, that might mean that my browser made a connection to o2.com,
or that it served something out of the cache without making any connections.

More importantly, is it a violation of confidentiality for *fewer* entities
to be told that I'm visiting a resource? (With the caveat that a
certificate could be crafted that leads to the same number of entities
being told.)

Jeffrey

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jan 2018 14:49:19 -0800

On Tue, Jan 30, 2018 at 2:00 PM, Jeffrey Yasskin <[email-masked]>
wrote:

>>>> 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?
>>>>
>>>
>>> result in content from o2.com. signed-exchanges change whether there's
>>> a physical connection to o2.com, but that physical connection isn't
>> I'm not sure what you mean by "not user-visible". That's the semantic
>> that we currently have that this proposal breaks.
>>
>
> How does the user know which physical connections were made? If I see
> o2.com in my URL bar, that might mean that my browser made a connection
> to o2.com, or that it served something out of the cache without making
> any connections.
>

What it definitely knows is that you didn't connect to some other random
server.

> to be told that I'm visiting a resource?
>
(With the caveat that a certificate could be crafted that leads to the same
> number of entities being told.)
>

The confidentiality issue is that the data that was sent to the client was
protected in transit, not shared with some random third party.

-Ekr

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 30 Jan 2018 22:47:46 +0000

> 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

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 30 Jan 2018 23:46:56 +0000

On Tue, Jan 30, 2018 at 2:50 PM Eric Rescorla <[email-masked]> wrote:

>>>>> On Tue, Jan 30, 2018 at 12:35 PM, Jeffrey Yasskin <[email-masked]
>>>>> > wrote:
>>>>>
> More importantly, is it a violation of confidentiality for *fewer*
>> entities to be told that I'm visiting a resource?
>>
> (With the caveat that a certificate could be crafted that leads to the
>> same number of entities being told.)
>>
>

Clearly we're not communicating well, so I'm going to take a night to sleep
on it and try to compose clearer questions. Thanks for taking the time to
reply so far.

Jeffrey

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 12:12:38 +1100

I don't think that any presumption of adoption is appropriate.

This draft creates an entirely new interaction model that takes the
process of serving a request out of the picture.  Before the working
group adopts this, the subject of having a request/response exchange
provided to a client absent any interaction between that client and a
server that is authoritative for the origin.

That is, when clients no longer talk to servers, what are the
ramifications for the ecosystem?

It seems like this work is intended to expressly avoid engaging on
that subject, but it's a huge shift for protocol interactions to
effectively take authoritative servers out of the loop.  The obvious
argument here is that this is an extension of caching, but this takes
the interactions from at least one to zero.

We should first decide if it wants to engage with that issue first
(I'm pleased to see some engagement already - the confidentiality
facet that ekr raised is definitely worth exploring further).  And
then whether it wants to *do* something about it. My sense is that
this is a much larger enterprise than can be contained in a mere 42
pages, so we should consider that cost and the other work we are
currently pursuing.

Frankly, I think that this is bigger than this working group.  I think
that the BoF that has been discussed probably needs to happen.

Personally, I am happy to engage on the architectural issue.  I have a
number of reservations about the design you present, but we can talk
about design once the bigger questions are addressed.

On Tue, Jan 30, 2018 at 3:56 AM, Jeffrey Yasskin <[email-masked]> wrote:
> https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html#change-log.
>
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/n7cZXSTwBTY/discussion.
>
> Thanks,
> Jeffrey

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 31 Jan 2018 07:07:11 +0000

Hi,

+1 to Martins comments understanding the impact on the ecosystem and effort being big enough to motivate a separate WG.

In particular, the how role of the origin and there being a "secure connection" to the origin fits into the browser security framework, not only how this is 
presented in a UI or not. This area is of course the expert area of browser vendors, and more particularly, the security teams there.

The browser security model is, in my personal opinion, not finished yet though and it would be safe to assume that it will be evolving.

Thus, any changes in the what 'origin' means and how responses are delivered to a client request need to be closely coordinated with browser security framework.

This is one of the reasons why this being a task beyond what this WG could handle need to be discussed in depth.

But I do think this problem- how to securely serve a client with responses from "multiple machines" other than the one(s) initially associated fetching the web app 
is an area where more work is desirable for the evolution of the http protocol suite.

I think the draft discusses the problem from an interesting angle, useful to taking a new look on how to move the discussion forward.

I would be willing to (re)engage in the area, both about architecture and protocol extensions.

Best Regards!
Göran

On 2018-01-31, 02:17, "Martin Thomson" <[email-masked]> wrote:

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 31 Jan 2018 21:45:02 +0000

On Tue, Jan 30, 2018 at 3:46 PM Jeffrey Yasskin <[email-masked]> wrote:

>>>>>> On Tue, Jan 30, 2018 at 12:35 PM, Jeffrey Yasskin <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> result in content from o2.com. signed-exchanges change whether
>>>>> there's a physical connection to o2.com, but that physical connection
>>>>> isn't user-visible in any case.
>>>>>
>>>>
>> The confidentiality issue is that the data that was sent to the client
>> was protected in transit, not shared with some random third party.
>>
>
> Clearly we're not communicating well, so I'm going to take a night to
> sleep on it and try to compose clearer questions. Thanks for taking the
> time to reply so far.
>

So, I start with a presumption that the confidentiality guarantee of TLS is
there to ensure some higher-level properties that humans care about. For
example, if Asha fetches a bank page, she doesn't want anyone but her bank
and her to learn her balance. If Davu fetches a social network page, he
doesn't want anyone but the network and himself to know the authentication
cookies that prove he's him. If Lupita fetches a page of medical
information, she'd prefer that *nobody* know she fetched it, but she'll
accept the author of the page finding out.

Now, say inter.com offers a collection of signed exchanges that folks can
download instead of talking to the exchanges' original authors. inter.com
can't offer Asha's or Davu's page because it can't authenticate to the bank
or social network to get those pages. inter.com can offer Lupita's page,
but how does she wind up fetching the https://inter.com/lupitas-page URL
instead of the https://medical.com/lupitas-page that it originally came
from? If she clicks a link written as <a href="
https://medical.com/lupitas-page">, she doesn't: she connects to the
original origin. Unlike some previous schemes I've heard of, there's no
attempt to auto-discover proxies or caches.

If she instead clicks a link written as <a href="https://
inter.com/lupitas-page">, she connects to inter.com. Today, inter.com might
record her visit and then use a 302 redirect to send her on to
https://medical.com/lupitas-page. She sees https://medical.com/lupitas-page
in her URL bar, and doesn't realize that she was forwarded through "some
other random server". That's today, with no changes. TLS's confidentiality
model did not prevent inter.com from learning about her visit.

What if Lupita's browsing https://inter.com/directory and sees a link to <a
href="https://medical.com/lupitas-page">? She's being careful and checks
her status bar before clicking, but, whoops, inter.com had attached an
event listener to the link, which either calls sendBeacon("https://
inter.com/visited-lupitas-page") or sets location.href to https://
inter.com/lupitas-page, and again tells inter.com about the visit.

If we implement signed-exchanges, https://inter.com/lupitas-page can host
the content directly. Lupita clicks the link to https://
inter.com/lupitas-page, sees her URL bar change to
https://medical.com/lupitas-page, and sees the content from medical.com.
The same people find out about her click: inter.com and medical.com, except
that it's possible medical.com doesn't even find out.

So, what practical effect did the change to signed exchanges have? There
must be an aspect to the story that I've missed--you have much more
experience here and wouldn't be worried over nothing--and I'd greatly
appreciate hearing it.

Thanks,
Jeffrey