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

Ben Campbell <ben@nostrum.com> Thu, 17 August 2017 01:04 UTC

Return-Path: <ben@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 BB662126DD9; Wed, 16 Aug 2017 18:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 DH6t8-hOoLX1; Wed, 16 Aug 2017 18:04:28 -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 B528A1323B6; Wed, 16 Aug 2017 18:04:27 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7H14MKB068807 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 20:04:23 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <CABkgnnVN5C5Veo77m6UVBoEqfM0YckfJv+qkisEoFFZ5yWiYVw@mail.gmail.com>
Date: Wed, 16 Aug 2017 20:04:22 -0500
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-Transfer-Encoding: quoted-printable
Message-Id: <832D4A7A-C387-48A3-BB66-701ED1658C44@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> <CABkgnnVN5C5Veo77m6UVBoEqfM0YckfJv+qkisEoFFZ5yWiYVw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/0k7_6dNSFNmc1UKWj53zuaEeEaM>
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:04:30 -0000

> On Aug 16, 2017, at 8:01 PM, Martin Thomson <martin.thomson@gmail.com>; wrote:
> 
> On 17 August 2017 at 01:52, Ben Campbell <ben@nostrum.com>; wrote:
> 
>>> 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.”
> 

WFM. I will clear.


>>> 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.

Also WFM.

> 
>> 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.

Okay.

[…]