Re: [Webpush] AD Review of draft-ietf-webpush-vapid

Costin Manolache <> Thu, 15 June 2017 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C985124BE8; Thu, 15 Jun 2017 12:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ViEBo_rGRhVN; Thu, 15 Jun 2017 12:54:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 657C61201F2; Thu, 15 Jun 2017 12:54:51 -0700 (PDT)
Received: by with SMTP id u12so34970974qth.0; Thu, 15 Jun 2017 12:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LzbZBlberQMk9x4ldTIi94nI9Iof6uT5izQPiWeGa9w=; b=vef/5/nFj5J7vtqq9VS0iyjOnfbACwrbWS4r6b95q71IKaTHXEBEdShWrF4xexNyAp PengVIEVz+RXpWopD9qXsAADE+JSpFmUX7BCm0g3gd9X/8iGrJsTXjAQWMvDfDiZ28ys X6QrgbeGqhkqgukcVyVEXnv1DNISlh6hXI96Plte4AeQ86jyZWS1AFjSBU8r8ubTnQ+O jklV+8RQzhZbBVv9WBRkVz/nmt6KPsAK4feTEo9VJfLcF8l8iMNLHZOy/5f8c9BQg32l Buy8P6CiOlAtp0TAW81ZLeugI6rYL6EMP5F3a0V5bgQH1pf9gxmPf/xNDyJVCVrEbE8O Uw2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LzbZBlberQMk9x4ldTIi94nI9Iof6uT5izQPiWeGa9w=; b=eq8eo3Y4OmsEoxibkoie8mh1O6fwFPrXEeAjsOp8oJbJVAU19yQTF4BZpUWAW9gLec f4IiQUBLNDFQCilP5SvZb/hmso0vbzyS03EOKGewG+/j8HNj6dqXsy6vVn1nCAeVUPAF V54CS7tmjivN1gJQ3jgwJKCjJSW/hHr70pPiAJ0RZ+TSfePaJHG//j3F9B8ZUBXaZ4kf DwfDtShFow+FvksITWwyeNB6taEpxhAZn7JqFR0ZlWC1KCGcMiMgVj2ouNjgKk5V2QXp 9T6hrqB7C3Ch7mmjRpX2qm+i/AkUj4jB2Dt1KfnDdNjON1n3JJ7wtacBraOhFVNuIH+s QB3Q==
X-Gm-Message-State: AKS2vOywTkNZdILfgY9PN83tZI1MWdYwNYsKF4JQlAfzUBdmGN4TglwY zV5kF3Nrpkxi6O//T6+0cD3tDuGvZw==
X-Received: by with SMTP id v38mr8913349qth.213.1497556490511; Thu, 15 Jun 2017 12:54:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 15 Jun 2017 12:54:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Costin Manolache <>
Date: Thu, 15 Jun 2017 12:54:50 -0700
Message-ID: <>
To: Adam Roach <>
Cc:, "" <>
Content-Type: multipart/alternative; boundary="001a1145c4f2a5f22a0552050a7c"
Archived-At: <>
Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Jun 2017 19:54:53 -0000

On Thu, Jun 15, 2017 at 9:20 AM, Adam Roach <> wrote:

> On 6/15/17 02:07, Costin Manolache wrote:
>> I think the 'negotiation' must happen much earlier - at subscribe time
>> (and in general case - out of band). At the time of auth, when VAPID
>> is used, the caller must have an endpoint that is bound to the server
>> public key.
>> If a EC256 public key is used at the time of endpoint creation - it
>> determines the signing algorithm as well.
>> So the 'challenge' happens long in advance.
> This makes sense, but it is a substantially different answer than Martin
> gave. I'll note that the subscription request doesn't indicate the
> algorithm to which the key corresponds, so the push server doesn't seem to
> have any ability to detect an algorithm mismatch until it's way too late to
> do anything about it.
> I'm not too caught up on what the details of the plan are, but I think
> that whatever is intended should be documented. I don't want to have this
> protocol painted into a corner when we decide to move on to other
> algorithms, and when I combine your and Martin's answers, it's not clear
> whether that's the case. I do get the impression, however, that this aspect
> of the system design hasn't yet been discussed by the working group. It
> should be.

I don't think Martin's answer is very different, the draft reflects what we
all agree on - but there are different ways to
extend it. The perspective is a bit different - our system still support a
'legacy' sender authentication scheme, based
on project IDs, which works using the subscribe parameters.

We've also seen few application servers migrate the 'sender id' and auth
scheme, as well as cases where app servers
ran into problems authenticating.


> /a