Re: [Webpush] Opsdir last call review of draft-ietf-webpush-vapid-03

[Martin Thomson <[e-mail]>]

Trimming ietf@

On 4 July 2017 at 01:57, Stefan Winter <[e-mail]> wrote:
> Cryptographic agility is ensured by requiring an all-new protocol in case a
> different algorithm is used, or any other protocol property is changed (the
> newly defined auth scheme "vapid" is hard-wired to ECDSA NIST P-256, and there
> is no version field in the JWT token). Considering that the JWT header and JWK
> fields describe their signing method, making it cryptographically agile,
> pinning the algorithm appears to be a strange choice (see the example in 2.4).

The problem here isn't that you can't switch to a different
cryptographic scheme in the format (clearly you can), but that you
don't know that your scheme will be accepted.   We opted to rely
*solely* on the mechanisms that HTTP provides for this, which means
that we can succinctly refer to this scheme as "vapid" with confidence
that that encompassed more than just the basic structure. If we wanted
to add - say XMSS - we would define a new scheme called "vapid-xmss"
and we might use the same basic arrangement.

Note that for a time we considered removing the JWT header in the
interest of saving those bytes.  In the end, we decided that HTTP/2
header compression would suffice.

> The last paragraph of Security Considerations remains a mystery to me. What is
> a "gradual migration"? With no key rollover, any change of key simply breaks
> all clients with using that key. The last sentence implies that such a hard
> failure is acceptable. That's a rather simplistic protocol design.

The issue of key rollover is dealt with in the section immediately
preceding the Security Considerations section (this is from the
editor's copy):

   An application server that needs to replace its signing key needs to
   request the creation of a new subscription by the user agent that is
   restricted to the updated key.  Application servers need to remember
   the key that was used when requesting the creation of a subscription.

In other words, you migrate to a new key by creating new
subscriptions. That doesn't create any hard failures.

"Gradual" here refers to making these new subscriptions gradually,
rather than all at once. The sentence you refer to:

   Gradual migration to a new signing key reduces the chances that requests
   that use the new key will be categorized as abusive.

This refers to the fact that if you are a large volume sender of push
messages (some large sites send many thousands per second), then
changing over all of your subscriptions at the same time might appear
as though you suddenly stopped and some unknown party just started a
denial of service attack.