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

[Peter Beverloo <[e-mail]>]

Hi all -

There are a number of concerns I have about thomson-webpush-encryption[1]
after implementing support for the draft in Chrome, most of which are
related to the generic nature of thomson-http-encryption[2].

The tl;dr is that while I believe that using the "aesgcm128" HTTP content
encoding with a single record is good, removing our dependencies on other
parts of thomson-http-encryption would significantly simplify webpush.

(To start off on a slight tangent, after further discussion with Mozilla
we have agreed to support P-256, despite our strong, standing preference
for using Curve25519.)


    (1) Allowing multiple values for the Content-Encoding header.

For efficiency reasons, an implementation may use alternative protocols
for the push service <--> user agent connection that are not HTTP-based.

This is the case for Chrome (and Android), where messages may be received
outside of the network stack and content decryption happens by using
the header values in combination with an aes128gcm encoding. Supporting
multiple values, e.g. encryption and compression, would be problematic.

Would it be reasonable to require a single value of "aes128gcm"?

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

The fact that both headers support comma-separated lists also seems
unnecessary for use with thomson-webpush-encryption.

Introducing yet another header it not great, but it would allow us to
provide a concise, to-the-point header only having "salt" and "dh"
parameters, in which the "rs" can be implied from the message's body.

      (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"?

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

thomson-http-encryption also allows use of the "key" parameter for
providing an explicit key. While this could be useful for broadcasts in
the future, we should explicitly disallow this until we get there.

Thanks,
Peter

[1] https://tools.ietf.org/html/draft-thomson-webpush-encryption-01
[2] https://tools.ietf.org/html/draft-thomson-http-encryption-01