Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

Martin Thomson <martin.thomson@gmail.com> Thu, 17 August 2017 01:01 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 438F613239D; Wed, 16 Aug 2017 18:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 zLulc9w7rN6L; Wed, 16 Aug 2017 18:01:03 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 3323612EC06; Wed, 16 Aug 2017 18:01:03 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id m34so24584101iti.1; Wed, 16 Aug 2017 18:01:03 -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:content-transfer-encoding; bh=HfuCURT0Fb+lR5ZMYekIKg6nzeT6r13KYJXXO8YtKjg=; b=oP55sJaVKMV7bDfnpQOFI43rNKsaODwn8yskURjjWOGTxcgMkBRnquQ+7OasQYLR1n E+uyJblILfIWyEJmcxhinn8LrAg3s80/RFXyrYC1hll8Gw+gGut3EC7EWkrTOlDoogBH Hs+wjUH6Z2hiPPOmX7v8z1U+dqP7AP0y34eyd8vNtPPPmIXc2y5DEOnhahGGfePjlyeE 8/9ki0PEsltcDZ6Z0BoSlhoS0Q7ninmX0EVXI55ZJRbsPGvRHCcpOnJ7ZZ563fGZgBoU rPLF054JDdWnIBdNLROpLfZkvLl4bm2aFL9Ygr86hlH3SdcssMfoqppv1S9dYpJu7guY XaSw==
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:content-transfer-encoding; bh=HfuCURT0Fb+lR5ZMYekIKg6nzeT6r13KYJXXO8YtKjg=; b=MqBI7VrIyO1zLoWGnv9ref4xQIjTmIZO7LaNZ2BYv3Pflc2YYLdmEueNRZ6BpYrNFO IYBFi9gQ4FZlSx+tkQQFIt8pYlN5DrIaUlaIF5Ymp940Eh1qfjx51vTEq+dQEcJxtc/G 8VZYNrDCOaq4JlVRf3WnGoTXGklDyyQjodwLLY8bOa0Cmc30ir4Ne+WqSjlx8q19686N 8Qkxm6Rr+FIvXJ7yGchAVzCKRaUvvKPg+QtHQZJz7L67Ag/1QIebh0OSoqygGGexIKcs 4sYmlI9l1Wwe4VHscnNJTx48JyqgBsbmq5WtGsmtzq0GV33AP3MY15GvUqhEsfJUrjTC 14Dw==
X-Gm-Message-State: AHYfb5j9tFxhQcajDJHDz4w5U59nFCeQebSUc3J6TByNNayg9IIgCUXo /I666nB4tA0VupmFtTFBLISL78zDkg==
X-Received: by 10.36.193.199 with SMTP id e190mr312646itg.122.1502931662535; Wed, 16 Aug 2017 18:01:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 18:01:02 -0700 (PDT)
In-Reply-To: <BFF47F9C-87C5-446D-A15F-9FB0706FA1A5@nostrum.com>
References: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> <CABkgnnU_QXMuVZMNycW=yj9-kU=v+Ooo5HV0v9p84zcYzdKA_Q@mail.gmail.com> <BFF47F9C-87C5-446D-A15F-9FB0706FA1A5@nostrum.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 17 Aug 2017 11:01:02 +1000
Message-ID: <CABkgnnVN5C5Veo77m6UVBoEqfM0YckfJv+qkisEoFFZ5yWiYVw@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-webpush-vapid <draft-ietf-webpush-vapid@ietf.org>, Phil Sorber <sorber@apache.org>, webpush-chairs@ietf.org, "webpush@ietf.org" <webpush@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/0YVHaADD_BQekcCSgcC9s-f3ulU>
Subject: Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)
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: Thu, 17 Aug 2017 01:01:05 -0000

On 17 August 2017 at 01:52, Ben Campbell <ben@nostrum.com>; wrote:
> That mostly looks good, modulo discussion below. I think you dropped the word “meaning” from the 8174 (was 2119) reference. Also, that RFC recommends specific boilerplate. (I’m not going to get wrapped around whether you use that specific boilerplate, as long as the meaning is clear.)

The master branch has the boilerplate.  I have updated the PR, which
no longer includes a change.

>> I think that "MAY" is entirely appropriate given the non-blocking
>> nature of the mechanism. A push service might look at the header
>> field, but not require the token. Maybe they just wanted to attach an
>> email address to a stream of messages (that's what we do).
>
> I think there’s a fundamental difference between not validating in the first place, and ignoring a failed validation. My point is not to say that ignoring it is the wrong thing to do, just that I think some more elaboration here is needed. Would it make sense to say something of the effect of “SHOULD NOT use the information from a token that has failed validation”?

That's easy.  MUST NOT even.  I added:  "A push service MUST NOT use
information from an invalid token."

>> In NSS and many elliptic curve libraries, you can create an EC key for
>> P-256.  You can then use that key for signing AND key exchange.  You
>> shouldn't though.
>
> Would it make sense to say “Some library implementations…”?

The PR says "Some elliptic curve implementations ".  I think that's better.

> Oops, that was a cut and paste error. I meant to quote the following sentence:
>
> " A push service MAY reject a
>    message that includes invalid credentials with a 403 (Forbidden)
>    status code. "

I'll respond below.

>>  This section defines behaviour in the case that a
>> subscription is limited to a particular application server key.  I
>> realize now that this might have been unclear, so I have reworded to:
>>
>> "A push service MUST reject a message sent to a restricted push subscription if
>> that message includes no "vapid" authentication or invalid "vapid"
>> authentication.  A 401 (Unauthorized) status code might be used if the
>> authentication is absent; a 403 (Forbidden) status code might be used if
>> authentication is invalid."
>>
>> This also allows me to clear up a minor gripe about the prescriptive
>> nature of the text regarding status codes.
>
> I like that paragraph better, but does it conflict with the text in section 2, as discussed in my DISCUSS?

The key point here is that the rejection mandated in Section 4.2 is
specific to *restricted* subscriptions.  The text in Section 2 (above)
is a more general statement.  I don't think that the two are in
conflict.

> I’ll go with Alexey’s separate response. That is, never mind.

:)