Re: [Webpush] Comments on draft-thomson-webpush-encryption

[Martin Thomson <[e-mail]>]

Thanks for the feedback Peter, I think that I agree with most of this,
though we should discuss the header split thing a little more.  More
inline.

On 16 October 2015 at 07:35, Peter Beverloo <[e-mail]> wrote:
> Would it be reasonable to require a single value of "aes128gcm"?

I will make that stipulation.  (I believe that we assume the value to
be set to exactly this, rather than checking that it is, which is
probably non-compliant, but it might allow a push service to save some
space...)

>     (2) Separation of the Encryption and Encryption-Key headers.
>
> Given that thomson-webpush-encryption mandates use of a single encryption
> record, an implementation only _needs_ the "salt" parameter from the
> Encryption header, and the "dh" parameter from the Encryption-Key header.
> The "rs" header can be implied, but could still be used to validate the
> single-record requirement.

Yeah, this comes down to the generality problem.  I think that the
split is still useful unfortunately, which isn't ideal (but HTTP/2
allows us to avoid the cost).

I've got more on this below, I think that there's a tweak that can
eliminate the worst of the cost.

>       (2a) Ambiguity about the meaning of the "keyid" parameter.
>
> Under what circumstances would the subscription id for which a message is
> received not be sufficient for selecting the keys, i.e. when would there
> be multiple key pairs per subscription?
>
> Is this an artifact of having the required data spread over two headers
> that both allow comma-separated lists, to match a "salt" with a "dh"?

In this context, it's used to correlate entries between Encryption and
Encryption-Key.  That's not great.  Here's what I propose adding:

An application server MUST include exactly one entry in each of the Encryption
and Encryption-Key header fields.  This allows the `keyid` parameter to be
omitted from both header fields.

>       (2b) Disallowing use of explicit keys (for now).

Yup, definitely (probably don't want to ever support that...)