[Webpush] AD Review of draft-ietf-webpush-vapid
Adam Roach <adam@nostrum.com> Wed, 14 June 2017 00:21 UTC
Return-Path: <adam@nostrum.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 C43CF127058; Tue, 13 Jun 2017 17:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 cL9UvyCUZ6B2; Tue, 13 Jun 2017 17:21:06 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2BD6C126DEE; Tue, 13 Jun 2017 17:21:03 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5E0L1lI027441 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Jun 2017 19:21:02 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: draft-ietf-webpush-vapid.all@ietf.org
Cc: webpush@ietf.org
From: Adam Roach <adam@nostrum.com>
Message-ID: <47693535-bfde-d2b3-4db5-98ffa05da2ad@nostrum.com>
Date: Tue, 13 Jun 2017 19:21:00 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/33ulEXJ-fBN3xtmekQxg8c21g-I>
Subject: [Webpush] AD Review of draft-ietf-webpush-vapid
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: Wed, 14 Jun 2017 00:21:09 -0000
VAPID authors -- This is my AD review for draft-ietf-webpush-vapid-02. I think the document may be ready for IETF last call, but I'd like some clarifications before sending it out. The first issue I'd like to have clarified regards agility of the crypto suite. This document hard-codes the signing algorithm as ES256. I'm familiar with the fact that documents will frequently do this kind of hardcoding, and then normatively update allowed algorithms in future documents; however, for all such cases I'm familiar with, there is a negotiation involved that allows for bilateral transition from one algorithm to another. For example, RFC7616 was able to include new algorithms because of the challenge/response nature of its authentication scheme. Since VAPID specifically does not include a challenge, application servers have no way of reasonably knowing what the push server might be capable of handling. I think the security section really needs a treatment of how this can be handled, since the obvious solutions with the current design are less than elegant. The second issue entails application server key rotation, especially when used without the Subscription Restriction mechanism described in section 4. My reading of the document (and I'll note, as a nit, that this is implied but not particularly explicit) is that the public key used to identify a server is a TOFU token; and that the only means a server has to detect impersonation is verifying that the public key is identical to previous uses. What is the system behavior intended to be when an application server needs to change its VAPID key gracefully; and what is the behavior intended to be when an application server loses its key unexpectedly? For subscription restriction purposes, I can see how servers could just change the key used for the subscription request; but when this mechanism is being used solely for the purposes of continuity of an application server's identity, it seems problematic. Finally, I'm curious about whether there was any discussion regarding the use of "application/json" rather than using the syntax defined by RFC6839 (e.g., "application/vapid+json"). My concern is that the use of a semantic-free syntactic designation here makes it more complicated to use push subscription requests for anything *other* than conveying a VAPID key in the future. If the intention is that push subscription bodies generically contain a JSON object with potentially myriad keys for a variety of unrelated purposes, please spell that out clearly (and I would still encourage the use of something less generic than "application/json" even in such a case). Nits: Although "vapid" appears in the protocol elements and section headers, it is never put next to its expansion in the document. Please consider changing the title to "Voluntary Application Server Identification (VAPID) for Web Push". The abstract's phrasing of "This can used to reduce the secrecy for push subscription URLs..." seems quite awkward. While this is necessarily one result of employing the described technique, it could hardly be construed as a goal. I suggest rephrasing. The JWT shown in the Authorization header field has an expiration date of 1453523768, while the JSON that claims to be its expansion shows an expiration date of 1453341205. Please make these match: implementors are likely to use the examples as part of testing their implementations, and this may cause unnecessary confusion. Please also double-check that the signature in the example is valid after performing this adjustment. Thanks! /a
- [Webpush] AD Review of draft-ietf-webpush-vapid Adam Roach
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Martin Thomson
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Adam Roach
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Costin Manolache
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Adam Roach
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Costin Manolache
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Martin Thomson
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Adam Roach
- Re: [Webpush] AD Review of draft-ietf-webpush-vap… Martin Thomson