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

Martin Thomson <martin.thomson@gmail.com> Tue, 04 July 2017 00:38 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3860012741D; Mon, 3 Jul 2017 17:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XhvvfSiOBmi; Mon, 3 Jul 2017 17:38:15 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E668213181C; Mon, 3 Jul 2017 17:38:01 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id t72so683012lff.1; Mon, 03 Jul 2017 17:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FQNd6qS0w87venUF2IPOfSzfCtA2bKRfNpUrmwutRgI=; b=UQXSf0PFF0eySNeVdO3cJdI2FmUOyNJrlzYAedyjKqkNl/Kr9lS/lDYejZrqkv/I/S npMuIPb8ALTJMZI4YFLFcCbGs1ljPb91RwBVRlyyEo+8lnw+/AlSvqsRA5ijyRy1yD9J 06GwxJ7sCGpEL6ujZI2P2fZ6+n7KBcnD4Eb7n50Vhzd8Rwgbu1fu9puIKQz7iaCTXsw7 5AmONZ6kdRqifwV6N6acRs3Z8Sj96JJKuwW5tRi9Gqwf5PJlgilntL0qQTBYuNPPVTFo gu8yJ6ek2yplJODBSDToR3bfTRbFGnkLJiJRRwHs30lNf4O3DWGL8YRg5IRbcVc4veo3 DUyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FQNd6qS0w87venUF2IPOfSzfCtA2bKRfNpUrmwutRgI=; b=YDsbe50Gkoh9jh/qoH08tCeUD+KxWMozkyHFFZ3jJTHMemgfZWOLhMD60EhDAb3MMp K/iWV//6/5KG+jcsCXqBTH485cNy78Wfoob16jubuJhWokeBaIDa+dj2xSO5QHaOuG5S 9AbUSOCQjoEWMFvnETTnqiv7KXeYtrqbY0MKEAi6nSI1wJvM5sM2Jl1IUv3Z82SKKycS Yq6WBAmaa03h/hmfR54kCI8gank7LA8r0gtvm2jIlwmyQhGZfgmItp4+UFDIFeY+tS42 iwzoYEFUHsgUNTuMVms1OnYneMFEqP5dcphEXFsv07RxGKFGsZq0vKIEgqwawadQ+8w9 MHRA==
X-Gm-Message-State: AIVw113OG8xCpZz7XB0uxic4ozeCCeYq393fyZIAWU/nW/cN8Lqu9oQh mRlNagHkRyAGP9zc5yabNIqHDqxDPDWuxUc=
X-Received: by 10.25.27.195 with SMTP id b186mr918593lfb.76.1499128680192; Mon, 03 Jul 2017 17:38:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.69.84 with HTTP; Mon, 3 Jul 2017 17:37:59 -0700 (PDT)
In-Reply-To: <149909744835.22804.5791695515985213782@ietfa.amsl.com>
References: <149909744835.22804.5791695515985213782@ietfa.amsl.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 4 Jul 2017 10:37:59 +1000
Message-ID: <CABkgnnUgrT6acFYSbnuZnHjg=Udw-oA1UqaUm7mxZusbc+WfLg@mail.gmail.com>
To: Stefan Winter <stefan.winter@restena.lu>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "webpush@ietf.org" <webpush@ietf.org>, draft-ietf-webpush-vapid.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/MMEYMpqb-S1Yy2XO56dU4a2pdH0>
Subject: Re: [Webpush] Opsdir last call review of draft-ietf-webpush-vapid-03
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jul 2017 00:38:18 -0000

Trimming ietf@

On 4 July 2017 at 01:57, Stefan Winter <stefan.winter@restena.lu>; 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.