Re: Concrete format for signed responses

[Jeffrey Yasskin <[e-mail]>]

On Wed, Dec 6, 2017 at 4:40 PM Jeffrey Yasskin <[e-mail]> wrote:

> 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.
>

Here you go: https://github.com/WICG/webpackage/pull/94. Thanks for the
example drafts.

Jeffrey

> 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
>