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

From: Peter Beverloo <[email-masked]>
Date: Fri, 16 Oct 2015 15:35:32 +0100

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Oct 2015 11:36:24 -0700

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.

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

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

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

---

From: Peter Beverloo <[email-masked]>
Date: Mon, 19 Oct 2015 18:02:07 +0100

Thank you for the updates, Martin!

> allows us to avoid the cost).

The expected values are now well defined, so this works for me. I will
liaise with our encryption experts.

> omitted from both header fields.

That works for me.

Thanks,
Peter

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Oct 2015 11:40:27 -0700

> Thank you for the updates, Martin!

I've pushed an update to the draft with these changes, since it's the
draft submission cutoff.  Nothing else has changed.