Re: Concrete format for signed responses

[Jeffrey Yasskin <[e-mail]>]

On Wed, Dec 6, 2017 at 2:45 PM, Mike Bishop <[e-mail]> wrote:
> Hm, then I’m not sure what sets up the deep links.  I’ll defer to those who
> know the tools better than I.
>
>
>
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-00
> requires the client to advertise support for the new frame types; you could
> steal the general structure from there.  I’d just say that servers MAY push
> signed resources for domains for which they aren’t authoritative only if the
> client has set the newly-defined setting.  Secondary Certs also defines new
> error codes, if you wanted to steal that.

Thanks. I'll look at that and draft-kerwin-http2-encoded-data, and
send y'all a PR Friday.

> What about omitting the tags entirely, and just have a two-element array
> with each element being a map?  [ request, response ].

Positional arguments are definitely plausible. I avoided them in order
to make it easier to extend this in the future if we need to. For
example, are we totally sure that we'll never want to represent
request payloads or trailers in a signed exchange?

Jeffrey

> From: Jeffrey Yasskin [mailto:[e-mail]]
> Sent: Wednesday, December 6, 2017 2:20 PM
> To: Mike Bishop <[e-mail]>
> Cc: HTTP Working Group <[e-mail]>
> Subject: Re: Concrete format for signed responses
>
>
>
> On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop <[e-mail]> wrote:
>
> Thanks, Jeffrey.  In parallel with other work that’s going on to make push
> actually usable, I’m excited about the ability to push non-authoritative
> resources in a secure way.
>
>
>
> A few smaller points on the draft, most of which wind up being feedback on
> Structured Headers more than your doc:
>
> 3.1:  The usual format is “section <foo> of [BAR]”; I think if you use that
> format, the html-ized copy will actually deep-link to the relevant section.
> You’re following the format from draft-ietf-header-structure, so we should
> fix it there instead.
>
> https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-04#section-1 has
> a deep link written like ([RFC7540], Section 9.1.2), so it's not primarily
> my syntax. I'm happy to use the 'of' syntax though if folks prefer.
> https://github.com/WICG/webpackage/pull/92
>
>
>
> 3.1:  MUST not => MUST NOT
>
> Fixed in
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1.
>
>
>
> 3.2.1:  You’re not the first to ask about lists in Structured Headers; the
> resolution nine months ago was that there’s nothing in Structured Headers to
> support that.  You’re demonstrating that there probably needs to be.  My
> solution in HTTP/QUIC was to violate the prohibition on repeated keys, but
> we need to resolve this before either Structure Headers and HTTP/QUIC lock
> down.
>
> https://github.com/httpwg/http-extensions/issues/281 for others to follow
> along.
>
>
>
> 3.6.1:  If you’re saying a client MAY do something other than what it MUST
> do per RFC7540, you might want to frame this as an extension.  In that vein,
> an HTTP/2 setting advertising support for this from the client might be in
> order.  You could also define a more specific error code for invalid
> unauthoritative pushes.
>
> Seems reasonable. Do you have any favorite extensions I could copy from?
> Origin Frame is close, but it merely defines something that
> https://tools.ietf.org/html/rfc7230#section-9.1 leaves vague, unlike this
> extension that explicitly reverses a MUST from RFC7540.
>
> In 3.4, the pseudo-map of arrays alternating keys and values feels odd.  I
> assume the reason you did this is so you have a normalized order for the
> signature, as CBOR “does not allow ascribing semantics to the order….”
> However, “[a] CBOR-based protocol can prescribe a specific order of
> serialization, such as for canonicalization,” and you already are.  (You
> specifically call out that you’re not using CBOR maps, so I presume you’ve
> been down this road.)  The advantage of your current scheme is that you can
> preserve the original order of the headers in the signature, meaning a
> client could detect changes / reconstruct them.  I’m not sure how critical
> that is, but this is the right list to give feedback on the semantic content
> of header ordering….
>
> I was avoiding maps for two reasons, the second of which I think I've mostly
> removed from the draft:
>
>
>
> 1) CBOR map canonicalization is a bit of a mess right now, with 3 errata
> proposing different changes to the suggested canonical map ordering, and the
> CBORbis effort not really sure which to pick:
> https://www.ietf.org/mail-archive/web/cbor/current/msg00264.html. If I were
> to pick a canonical order, I'd prefer
> https://www.rfc-editor.org/errata_search.php?rfc=7049&eid=4964, pure
> lexicographic order ignoring item lengths. Does that sound good to you?
>
>
>
> 2) I was thinking of a CBOR format for transmitting the exchange to the
> client. For that, it's probably important to send the response headers
> before the response payload, but 'response' sorts after 'payload' in either
> canonical map ordering. This *may* also be useful for
> https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html#cbor-representation,
> where an implementation could stream the request and response into the
> signature verifier before receiving the payload, with the current ordering,
> but couldn't if it had to put the payload first. Do we want to 1) play
> spelling games to put things in the right order, 2) use arrays in only the
> places this matters, 3) use arrays everywhere, or 4) ignore this since it's
> not in the current proposal?
>
> On the whole, I’m really interested in this direction, and this is a solid
> starting point for a way to get there.
>
> Thanks (\o/)
>
> Jeffrey
>
>
>
> From: Jeffrey Yasskin [mailto:[e-mail]]
> Sent: Tuesday, December 5, 2017 1:20 PM
> To: HTTP Working Group <[e-mail]>
> Subject: Concrete format for signed responses
>
>
>
> Hi all,
>
>
>
> I've published
> https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html
> to follow up on
> https://lists.w3.org/Archives/Public/ietf-http-wg/2017JulSep/0385.html with
> a concrete proposal for the Signature header.
>
>
>
> I made several choices in this design where another tradeoff would be
> totally plausible. Let me know where you'd prefer something different.
>
>
>
> Some interesting aspects of this update:
>
>
>
> * The signature covers the URL, so it's really a signed "exchange" rather
> than just a signed response.
>
> * To simplify the Signed-Headers header, it's not possible to customize
> which parts of the request are included in the signature. Exactly the method
> and effective request URI are included.
>
> * The signing key can either be a certificate's key or a raw ed25519 public
> key. The first supports origin-trusted certificates and other complex forms
> of trust, while the second supports
> https://github.com/mikewest/signature-based-sri and other ways a public key
> might be trusted out-of-band. Attentive folks will notice that this means
> signed exchanges are no longer necessarily *origin*-signed.
>
> * Certificate chains are fetched and cached from a URL rather than bundled
> into the Signature header. Normal use is likely to Push the chain for a
> group of signed exchanges.
>
> * There's a way to update the signatures for a response without re-fetching
> the whole response.
>
>
>
> I'll be updating
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
> as you point out things I should change.
>
>
>
> Thanks,
>
> Jeffrey