Subject: [Webpush] ietf-webpush-encryption - untrusted push services

From: Peter Beverloo <[email-masked]>
Date: Mon, 2 Nov 2015 16:12:11 +0900

We don't trust the intermediary. What if they are the attacker?

    (1) There's a possibility of contributory behaviour with other DH
groups.

E.g. using an ephemeral key of 0 (or 1) forcing the shared key to be zero,
or using one of the 12 "forbidden" Curve25519 values.

Since P-256 is a prime-ordered group this doesn't apply today, but it would
be a subtle issue if we were to change curves.

    (2) The client is vulnerable to DoS attacks.

Authentication only happens while deciphering the payload with the
calculated content encryption key, which can be a heavy operation for
lower-end devices. Being able to authenticate the message before doing
public key operations would mitigate this.

One option is for the UA to create a HMAC key per subscription, which it
will transfer to the application server, together with the public key, upon
creating a subscription.

The application server will then HMAC the whole message -including the
ephemeral key- before sending it to the push service. This mitigates both
concerns.

Thanks,
Peter

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Nov 2015 10:21:54 +0900

> We don't trust the intermediary. What if they are the attacker?

I agree, this is the most interesting attack.  Requiring https:// as
we do removes most opportunities for all other attackers.

>     (1) There's a possibility of contributory behaviour with other DH

I've done my reading on this now and realize that this is (probably) a
bit of a minefield.

See http://cr.yp.to/ecdh.html#validate
...and for the opposing view:
http://vnhacker.blogspot.jp/2015/09/why-not-validating-curve25519-public.html

The curve25519 draft doesn't reflect any of this nuance, which I find
interesting. I haven't followed the CFRG discussion, but I did find
this thread: http://www.ietf.org/mail-archive/web/cfrg/current/msg06501.html

The concern here is that this protocol depends on contributory
behaviour.  That's a valid concern.  At a minimum, we should consider
having some considerations on this.

A perhaps better approach would be to change the key derivation to
remove the dependency on contributory behaviour.  I need to think
about that a little.  This is a subject that needs to be addressed in
the http working group soon.

> be a subtle issue if we were to change curves.

Yes, 25519.

>     (2) The client is vulnerable to DoS attacks.

If the push service is the attacker, then they have much better DoS
options available than what you describe, especially for a
battery-powered device.

---

From: Adam Langley <[email-masked]>
Date: Tue, 3 Nov 2015 10:14:35 -0800

On Mon, Nov 2, 2015 at 5:21 PM, Martin Thomson <[email-masked]> wrote:
> interesting.

It currently specifies that implementations MUST reject small-order
points as a defense-in-depth. However, I though that would be
relatively uncontroversial and was wrong. Because of that, it'll
change.

But, still, you can't depend on contributory behaviour. It's just not
a property that's guaranteed.

Cheers

AGL

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Nov 2015 09:29:42 +0900

> a property that's guaranteed.

Right.  I have requested that you put that in the security
considerations.  I am on the hook to produce a revision to the content
encryption draft that addresses the contributory behaviour concern.  I
expect that to be fairly simple in this case.  Expect something in a
week or so.