Architecture for removing real-time connections to origin servers

I posted a general use cases document to the ART list back in August, as
Martin had requested at IETF99 (
https://mailarchive.ietf.org/arch/msg/art/gaS8EHxsdzcyPCaSqSyWSh-WbMY), but
folks with architectural concerns didn't chime in there, so this seems like
the most promising list to collect such concerns.

What architectural worries do folks have? Who would show up to a BoF on the
subject?

There are certainly some concrete security implications to allowing a
client to render a response without a real-time connection to its author,
and I've tried to list those in the draft's security considerations
section, but the use of "architecture" and "ecosystem" imply that you're
thinking of other effects. What are those?

Thanks,
Jeffrey

On Tue, Jan 30, 2018 at 5:12 PM Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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 <jyasskin@google.com>
> wrote:
> > 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
>