RE: Origin-signed responses

Hi Jeffrey,

You make a good observation. draft-pardue-quic-http-mcast-01 skips some details, we have an implementation that does some additional things that aren't explain anywhere (yet). Since this is Alt-Svc, we try to follow those security expectations in our implementation, to form a bit of a closed loop. The sender's signature keyID is in the form of a certificate that is valid for the sender's source IP and the origin.

Is that similar to draft-yasskin-http-origin-signed-responses?

draft-cavage-http-signatures leaves the usage of KeyId open, so looking ahead we'd have to profile or mandate our approach. If your proposal is stricter, that could help simplify things for us in terms of documentation and getting wider adoption/support.

Lucas
________________________________
From: Jeffrey Yasskin [jyasskin@google.com]
Sent: 06 September 2017 19:47
To: Lucas Pardue
Cc: HTTP Working Group
Subject: Re: Origin-signed responses

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<http://example.com> domain.

Jeffrey

On Fri, Sep 1, 2017 at 10:36 AM, Lucas Pardue <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>> 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 [jyasskin@google.com<mailto:jyasskin@google.com>]
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 <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>> 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