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

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

Received on Wednesday, 31 January 2018 01:13:35 UTC