Re: Origin-signed responses

[Jeffrey Yasskin <[e-mail]>]

draft-yasskin-http-origin-signed-responses does plan to require that the
certificate is trusted for the sender's origin. My proposal doesn't require
the certificate to include the sender's source IP, so if you need that in
addition to the origin, you'd wind up profiling mine too.

On Wed, Sep 6, 2017 at 12:51 PM, Lucas Pardue <[e-mail]>
wrote:

> 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 [[e-mail]]
> *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 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
>>
>
>