Re: Concrete format for signed responses

On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop <mbishop@evequefou.be> 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:jyasskin@google.com]
> *Sent:* Tuesday, December 5, 2017 1:20 PM
> *To:* HTTP Working Group <ietf-http-wg@w3.org>
> *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
>