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

[Martin Thomson <[e-mail]>]

On 16 August 2017 at 12:35, Adam Roach <[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.

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.

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.

Then we have to decide whether this is a mandatory part of the
mechanism.  It's marginally easier if it isn't, but the arguments ekr
has presented suggest that he thinks it should be.  That makes the
deployment story harder.  For that, we really would want to exercise
the cryptographic agility Adam refers to here.  It's possible that we
don't need to worry too much about removing the old stuff on the basis
that it's all voluntary anyway, but now there are two things that need
to be implemented and supported.  What incentive have we provided to
use the new thing as opposed to the old thing?

To answer Ben's question: there are a small number of push services
(one for each browser, effectively http://caniuse.com/#feat=push-api),
but a LOT of application servers.

And to briefly address the costs of the other alternative: Doing
something like token binding has a bunch of implementation costs.  It
cross layers in ways that make it difficult to both implement and
deploy.  For instance, we couldn't deploy it without
draft-campbell-tokbind-ttrp being supported by our vendors.  This is
the same reason we considered and rejected client certificates for
this - one of the many alternatives that were considered.

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'd
be interested in learning whether the IESG has an opinion on the
subject.  A statement of policy might be valuable.