Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Wed, 17 Sep 2014 08:28:01 -0700

Adding [email-masked] since I failed to list it as a recipient in the
datatracker until just now.
Alissa

On 9/17/14, 7:54 AM, "Stephen Farrell" <[email-masked]> wrote:

>Stephen Farrell has entered the following ballot position for
>charter-ietf-webpush-00-00: No Objection
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>
>The document, along with other ballot positions, can be found here:
>http://datatracker.ietf.org/doc/charter-ietf-webpush/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>I've no objection to this going for external review.
>
>I am concerned however about the security goals here and
>would like to be clear about those before this is chartered.
>(If they remain unclear then I figure that'd be worth a BLOCK,
>but I'm fine if this is sorted before, during or after external
>review so long as it is sorted.) Apologies if some of the
>deployed proprietary schemes already address all of this,
>I'm not that familiar with 'em.
>
>I think there are 3 security things I'd like to be clear about:
>
>First, I think it needs to be possible for pushed data to be
>encrypted and authenticated at all times. I'm not sure if all
>pushed data MUST or SHOULD be so protected but that
>seems like something the WG would need to discuss. And
>there are issues related to authorization (by the device
>owner) here too. Given that that might not be so easy I
>think it'd need to be explicit in the charter or am I missing
>something?
>
>Second, I think that there's a need for some analysis about
>any differences in security between pushed and other data
>for specific applications. (The security needs to be
>commensurate I figure or else we're doing the user a
>disservice telling them about application security properties.)
>I'm not sure how that'd be reflected in the charter but I'd
>like to chat about it. For example, my phone gives me a
>push/sync option for email and I don't know if that provides
>the same or different security compared to IMAP. I think
>the same issues arise here.
>
>Third, the charter says "This protocol will include the ability
>to push the same message to multiple devices (broadcast)."
>I have no clue how that can be done with the same security
>features as a secured individual push. Can you explain a
>bit? Arm-waving is fine, but I'd like to know that the broadcast
>requirement is not going to mean that in practice all pushed
>data ends as cleartext. Note: I am not asking if a secured
>broadcast is needed here, I'm asking if the highly likely
>desire for an insecure broadcast will result in insecure
>everything.
>
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Sep 2014 07:57:17 -0700

The subject of security in the context of push is something that I've
sunk a fair amount of thinking into.  That doesn't mean I've given up
on it (I need to talk to Senor Barnes about whether using WebCrypto on
something here might help...).

I believe that the key facts that define the security architecture are:

 - An application uses web push to talk to itself.

 - The web push server carries an opaque payload.

The key concern being that confidentiality and integrity are assured
against the push server itself.  The rest we protect with TLS in the
usual fashion.

I definitely think that we want this to be secured, but as it stands
securing pushes is out of our hands.  Applications, as they run in
both the browser and some random server, both generate and consume the
pushed data.  The point is - at least from my perspective - to enable
an entirely private protocol.  In all senses of that word :)

At best, I think that we want to do two things:

 1. document the properties of the channel (as above)

 2. describe a potential method for securing pushed data from the push
server; that being one where key agreement occurs at the time that the
device registers a push endpoint with the server

For broadcast, the same basic model applies, noting of course that the
set of discrete entities who hold the same key is likely a larger
number than 2.  That's obviously a very different situation from that
perspective.  All instances are the same application, and the
information that is carried is necessarily the same.

On 17 September 2014 08:28, Alissa Cooper <[email-masked]> wrote:
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Sep 2014 15:17:23 +0100

Hi Martin,

>  - An application uses web push to talk to itself.

You're assuming a we/JS client there right? If so that might be a good
way to characterise this. So e.g. an IMAP MUA is out of scope?

>  - The web push server carries an opaque payload.

Opaque to whom would be the question, but skip that and see below.

>  1. document the properties of the channel (as above)

Certainly. I assume you mean the security properties there,
so that'd include who has/shares what keys with whom, right?

> device registers a push endpoint with the server

Hmmm. I'm not getting how its ok for us to move from pretty
well-defined security/privacy properties in the non-pushed
case to un-defined dunno-what security properties in the push
case. If that is what you're saying how is it ok? If that's
not what you're saying then I'm missing something (which is
fairly common:-)

Can you also speak to Adrian's good point about the privacy
and other aspects of consolidating things?

> information that is carried is necessarily the same.

Even more hmmm:-)

All instances are the same application is very far from
meaning that its ok for them all to share a single symmetric
key. (And how you might do that is somewhat mysterious
anyway, see also the DICE wg discussion on DTLS/multicast IP.)

But, as I said, I'm fine that this go for external review
and that this be discussed during that time.

Cheers,
S.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Sep 2014 08:18:33 -0700

> way to characterise this. So e.g. an IMAP MUA is out of scope?

Absolutely not.  Obviously that is the use case required by the Web
API.  The protocol however doesn't need to presume any dependency on
that, in much the same way that WebRTC has escaped from the confines
of the browser.

On the rest, I actually agree.  I didn't find that answer particularly
satisfactory either.  It's kinda that status quo that I lived with
when I worked with this at Skype.  There we used that "talking to
yourself" thing to avoid the need for anything better.  I think that
we can improve on that in the web context.  I've some ideas here that
I need to check for viability, particularly since they require certain
sacrifices.  Expect a more satisfactory write up in a day or so.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 11:34:39 -0700

> sacrifices.  Expect a more satisfactory write up in a day or so.

I wanted to expand on this, because I realize that there was some confusion.

I still believe that we need nothing in the charter, because there is
nothing that the *protocol* can do to enforce this and adding
something to the charter creates a commitment to do something that is
essentially impossible within the defined scope.

That said, this isn't a lost cause.  I've a way to essential force
end-to-end security for the entire solution.  That requires changes to
the web API.

The basic idea here is to have the browser provide an encryption key,
with which the application is required to protect pushed messages.  If
messages aren't encrypted and authenticated, then the browser discards
them.  Nothing prevents the application from sharing messages with
others, but that requires extra work.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Sep 2014 21:22:52 +0100

Hi Martin,

> I wanted to expand on this, because I realize that there was some confusion.

There is. In my head at least:-)

> others, but that requires extra work.

So I'm sorry for being slow but I'm not getting it. The above seems
to be saying that the charter should be silent on security and also
that adding some security would require changing a W3C API. Neither
of those sound at all hopeful from my POV. But I'm probably getting
some of that wrong.

S.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 13:53:53 -0700

> of those sound at all hopeful from my POV. But I'm probably getting

We can't ensure that there is security in the same way a router
cannot.  (That is, unless there is some magic thing I'm not aware of.)
 The most we can do is produce a motherhood statement.

I'm hopeful.  I've had discussions with the Chrome team on this and
they were really excited about the prospects of getting end-to-end
security for push.  Yes, relying on external parties sucks, but I
don't see a good alternative.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Sep 2014 22:07:16 +0100

Hiya,

> don't see a good alternative.

Good that folks are keen on doing stuff. And there's always going
to be a distinction here between what we can define (e.g. a way to
use TLS or whatever for pushed stuff) and the extra steps that
are needed in deployments.

Do we have any worked examples of using security (and caring
about privacy) here though? I remain concerned that its too easy
to just say "turn on push" for <foo>, where the security and
privacy consequences of doing so are unknowable for <foo>. But
maybe I'm worrying over not so much and a worked example will
help.

S.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 15:10:11 -0700

> maybe I'm worrying over not so much and a worked example will

OK, so the intent of the proposed security mechanism is that the
easiest thing to do is to provide end-to-end security.

How we'd do that is the API returns two things to the application
running in the browser: a location to send messages and a key with
which to encrypt them.  If you don't encrypt them, then the browser
will fail to deliver pushed messages.

The keying material isn't used in the message delivery at all.  An
application running on the server can send anything to the browser
over the push channel, but if the message doesn't decrypt and
authenticate with the selected key, it doesn't get delivered.  It's a
little odd to effectively hold functionality hostage like that, but I
think that it will work.

I won't lie, we can't prevent someone outside of the browser context
from only using the hop-by-hop security mechanisms.  I can't help but
be optimistic that a demonstration of feasibility will help shift
those use cases too.  It's possible that this sort of mechanism could
be enforced at the operating system level in the same way.

Ever the eternal optimist, I suppose.