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, 04 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.
- [Webpush] Opsdir last call review of draft-ietf-w… Stefan Winter
- Re: [Webpush] Opsdir last call review of draft-ie… Adam Roach
- Re: [Webpush] Opsdir last call review of draft-ie… Martin Thomson
- Re: [Webpush] Opsdir last call review of draft-ie… Carsten Bormann
- Re: [Webpush] Opsdir last call review of draft-ie… Martin Thomson
- Re: [Webpush] Opsdir last call review of draft-ie… Martin Thomson