Re: Origin-signed responses

[Jeffrey Yasskin <[e-mail]>]

Thanks. In draft-pardue-quic-http-mcast-01 you do have enough of a channel
in the Alt-Svc header to transmit a signing key, so you could use
draft-cavage-http-signatures, but the spec and examples show the public key
being identified alongside the signature, which isn't enough to establish
that the expected sender is actually the one that signed the message.

draft-yasskin-http-origin-signed-responses would be harder to use
incorrectly inside higher-level protocols, since it insists that the key is
trusted for the example.com domain.

Jeffrey

On Fri, Sep 1, 2017 at 10:36 AM, Lucas Pardue <[e-mail]>
wrote:

> We've written up some of it in the I-D draft-pardue-quic-http-mcast.
> Section 6 and appendix B are particularly relevant.
>
> We expect the checks to happen in the application code, running in or
> above a HTTP UA of some sort. E.g. an app that incorporates libcurl, or
> JavaScript application code executing in a browser.
>
> Lucas
> ________________________________________
> From: Jeffrey Yasskin [[e-mail]]
> Sent: 01 September 2017 18:18
> To: Lucas Pardue
> Cc: HTTP Working Group
> Subject: Re: Origin-signed responses
>
> On Fri, Sep 1, 2017 at 10:04 AM, Lucas Pardue <[e-mail]>
> wrote:
> > Hi Jeffrey,
> >
> > I spotted this yesterday and found it an interesting read, so thanks for
> starting a discussion.
> >
> > Your draft references draft-cavage-http-signatures, which we have been
> using on a project to add some authenticity to HTTP/2 pushed content. I'm
> still processing your draft but can see how it might complement our
> approach or help satisfy the higher goal.
> >
>
> I'm glad to hear it. :) What kind of software winds up checking that
> authenticity? How do you transmit the public key? Do you need to
> revoke keys or prevent downgrade attacks? (I'd be happy to read a
> document about this, if you have one, rather than making you retype it
> on the mailing list.)
>
> Thanks,
> Jeffrey
>