Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

[jr conlin <[e-mail]>]

If I may lend a bit of prospective from the point of view of the Push
Service provider.

We enjoy VAPID because it provides us a way to associate contact
information with the data we receive. It's (in theory) voluntary, and we
can prefer feeds that provide the data. VAPID provides us a reasonably
low cost means to "validate" the information we get *if* the requested
URI was secured using the same key, as well as prove that there has been
no casual MITM alterations of data. As Martin notes, the bar is set
fairly high for an attacker sending malicious data to the remote customer.

>From our point of view, VAPID isn't really a security device, it's a
contact device. It's equivalent to someone stapling their business card
to their letter, and is most useful for our ops folk when things go
awry. That's why we accept feeds that use VAPID even if the requested
URI was not secured. In addition, our most pressing concern is with
sites that perform non-hostile abuse. (e.g. we currently get near 2:1
traffic from sites sending to URIs that are no longer active, and do not
provide good ways to contact their operations.)

That said, we still encourage frankly horrible security practices around
VAPID just so that the barrier to use is as low as possible. We find the
data to still be that useful. For example, we encourage application
servers to cache the VAPID header for as long as possible to reduce the
publication load.

Naturally, we look forward to the guidance provided by the working group
and will adopt their suggestions, but I did want to offer what the more
hands-on usage of the spec has been so far.

On 8/16/17 5:55 AM, Eric Rescorla wrote:
>
>
> On Tue, Aug 15, 2017 at 10:09 PM, Martin Thomson
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 16 August 2017 at 12:35, Adam Roach <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     > On 8/15/17 9:31 PM, Ben Campbell wrote:
>     >>
>     >> My knee jerk response is to agree with Ekr. But it’s worth
>     discussing how
>     >> big of an incompatibility with existing code people are talking
>     about. Are
>     >> there a lot of deployed services that support vapid? Do people
>     think that
>     >> existing implementors will choose not to implement/deploy the
>     additional
>     >> protection?
>     >
>     >
>     >
>     > My inclination is to ask the WG to weigh in on this issue in
>     particular.
>     > I've received some pretty confident responses indicating that
>     VAPID has no
>     > issues with crypto-agility. Given that such is the case, it
>     seems like the
>     > question of how many deployed implementations we have is pretty
>     irrelevant:
>     > if we can't change crypto schemes at scale, then we shouldn't
>     publish this
>     > document anyway.
>
>     No change is free.  We'd first have to establish whether the change is
>     a net gain.
>
>     The presumption here seems to be that the presented design is
>     unconditionally superior.  That's not true.  This is a trade-off, and
>     - in my opinion - not one that favours any change.
>
>     For me the important point here is that the proposed change (in any
>     form) is of fairly marginal value.  Yes, the IETF is investing in
>     anti-bearer-token-theft technology, but in this case what you get is
>     the ability to send a message to user agent and wake it up.
>
>     You get that after stealing two pieces of information: the push
>     subscription URI and this token.  (That's assuming that the first was
>     not already sufficient, which it is in some cases.)  You can't send
>     arbitrary data, for that you need two more pieces of information: a
>     public key and authorization code, and neither of these appear on the
>     HTTPS connection from which the other items were stolen.
>
>
> This is a rather odd argument, as it also applies to the mechanism in
> this document as a whole.
>
>
>     So that's benefits.  Let's talk about costs.
>
>     If we take the suggested design the biggest challenge is key
>     management for K_p (the key that the push service would have to
>     maintain).  Maintaining a set of keys across a globally-distributed
>     service isn't free.  Given that key compromise would undermine the
>     effort we'd be putting in here, you also need a strategy for updating
>     those keys and revocation of old or compromised keys.  For that you
>     want multiple keys, which means key identifiers in messages.  You also
>     need some way of having application servers update their view of what
>     keys are current, maybe using expiration times.
>
>
> You raise several issues here:
>
> 1. The cost of coordinating the key. I agree that this is a real cost
> to the mechanism I proposed here, though it's possible to mitigate it
> in a number of ways (e.g., by having a centralized oracle for doing
> the verification, given that you don't need to do a lot of EC
> computation here).  
>
> 2. The need for revocation. You don't actually need that here, just a
> key update mechanism and a way to tell the app server "use this new
> key". But this latter mechanism is the same one you use for key
> updates and for updates to the mechanism, which this document implies
> the WG thinks is easy.
>
> 3. Key identifiers in messages are just specification work, so I don't
> think that that's a strong argument (see below).
>
> 4. Yes, it's a concern if these keys are compromised, but note that
> even if that's so, the security of the system reduces back to a bearer
> token (because you need the DH public key and the signed JWT), so that
> doesn't seem like much of a cost.
>
>
>     Technically, we also have to work out what to cover with the MAC.  My
>     experience with HTTP and signing suggests that this isn't as trivial
>     as it might seem.  I think that we could canonicalize the push
>     subscription URI, Content-Encoding header field and payload and be
>     reasonably sure that the MAC couldn't be transplanted.  Probably also
>     the RFC 8030 TTL, Urgency and Topic header fields, which suggests that
>     there needs to be a way to sign any new and relevant header fields
>     that might be added later.  This would need some more analysis than
>     I've given it here.
>
>
> I agree that there are complexities here, but they're complexities
> that are motivated by actually trying to design something with
> stronger security properties. More generally, they are costs to the
> WG, but not really costs to the world at large.
>
>
> Finally, I think this discussion has ratholed a bit on this particular
> counter-proposal. My point isn't that you should do this particular
> thing but rather that it seems like the WG decided on a bearer-token
> model without giving sufficient consideration to alternatives that
> have better security (of which this is merely one). The fact that I
> was able to produce two such alternatives in a few hours (which I'll
> concede are not in every way superior) and your response was not "yes,
> we considered those and here is a pointer to the WG archives" seems to
> lend that point some plausibility.
>
> As I said initially, this is ultimately a WG decision and I'm fine
> with being told by the ADs and the Chairs that they believe sufficient
> consideration has been given, in which case I'll withdraw my discuss.
> So far I haven't heard that.
>
> -Ekr
>
>     p.s., It's been a while since I've been on the receiving end of the
>     old "your code doesn't matter, you took a risk implementing an I-D"
>     argument.  As an argument it kinda stinks.  I'm embarrassed to confess
>     that I've used it in the past, despite reminding myself not to. 
>
>
> I think I explicitly labelled this argument as flippant, but I also
> don't think it's valueless, especially when put up against "Three
> large companies implemented and are too lazy to change".
>
>
>
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush