Re: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT)

Martin Thomson <martin.thomson@gmail.com> Wed, 16 August 2017 01:24 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 2615B13238E; Tue, 15 Aug 2017 18:24:19 -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 LCdtL08j-K2J; Tue, 15 Aug 2017 18:24:17 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 D718F120713; Tue, 15 Aug 2017 18:24:16 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id 77so11776829itj.1; Tue, 15 Aug 2017 18:24:16 -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=+NYGfQ0yWGYQ/d/2HLBeuqywQmbru3Rjf59Gxj+n/kQ=; b=HnYvgWgQ/P2V9GUK7RUY23TTyQPnuNfp2ZJSpgxBOL4FLXMa0zGMy1asmjlsw623qP TEgNWH0BVtlV0Mc+ogecsIthKzZAuDzmJ2VCP3uegkXWN/n/tGxwebNx6dn4272nLIXY yEzJtHr2PSL3JU9GrIUugCn/oiAYHhnRoKHQlLKcurq9Zbv1BG4McmRdGozTdRpot0yz f9tfosHM6UA3ysJckgBIS4H9FMVsj11knaFUeVvvq4LpwYRx5SUdmkSjzix5tOhOvQ8/ TYG7eyO9TXiiM9cBhYQ5+nToONNk/m8XXoKYmakwlXtww7mi5CKwVQi2GvJ4zwoS1lA5 uIww==
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=+NYGfQ0yWGYQ/d/2HLBeuqywQmbru3Rjf59Gxj+n/kQ=; b=sXliwKN9mbaCVv0XQOiP8t8IpFMkO29vtHbycpllNFg2KaDxIn9G4ZhsTblUEeo+df 3x8VNZ1grXXljrwsBa+ASXqbCKEoAQcBah9XjVIv8zQNg3daJVcHYLedln3eBs+3ULGy BBcNeZZDvj615bGVeLGJfM434eC3Nod8JubsqCz40jb7eAJTSs5oULR/XN3oDQG9z2BH P2dUCUA/vHkbWo4iRSfzzzfnbEPm/eyEqpTkYrfP3TAHtzSgMb7eYfCS2Kf7hbUSML31 LS0DHNuGEcU22ZqKemN8mvgMinOSQHbgs2NtzP+pOxRdJZw42S5l804dY6nkH36asUjH BEBg==
X-Gm-Message-State: AHYfb5icIBfTX4rdYIxiVGFXWOCVSrr9U95zpOBsmNgifBSaydyGwbEI SLDrAKC4PnWQ7sM3zISXJxPTHNttkQ==
X-Received: by 10.36.120.16 with SMTP id p16mr404989itc.151.1502846656156; Tue, 15 Aug 2017 18:24:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 18:24:15 -0700 (PDT)
In-Reply-To: <CAP8-Fq=aFgGzEL3foLNEU+SeYnXB8_QSdpKWa=QKgBuvomBCQw@mail.gmail.com>
References: <150281715482.21106.3346502830630897599.idtracker@ietfa.amsl.com> <CAP8-Fq=aFgGzEL3foLNEU+SeYnXB8_QSdpKWa=QKgBuvomBCQw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 16 Aug 2017 11:24:15 +1000
Message-ID: <CABkgnnWut8YgFoCe0=Htm7FHHPV=x24AmYU=Ztdc==4DgmWoSA@mail.gmail.com>
To: Costin Manolache <costin@gmail.com>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, draft-ietf-webpush-vapid <draft-ietf-webpush-vapid@ietf.org>, webpush-chairs@ietf.org, "webpush@ietf.org" <webpush@ietf.org>, Phil Sorber <sorber@apache.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/8mya8yAyLeudJJ0Za8ZVuPVpsoY>
Subject: Re: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-vapid-03: (with 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: Wed, 16 Aug 2017 01:24:19 -0000

We have previously discussed the problem of discovering whether a
server supports a particular authentication scheme.  On the API side,
we didn't resolve to make a change that would add a mechanism similar
to what we use for content coding (see
https://github.com/w3c/push-api/pull/262 for that discussion).  This
is approximately what Costin is talking about here.

What has changed since that time is that I have learned that some push
services *require* authentication.

For that reason, though it adds delays to sending when authentication
fails, I'm inclined to add a challenge.  It would be empty, but it
would allow a server to insist on authentication in a transparent way.

It IS easy to define: https://github.com/webpush-wg/webpush-vapid/pull/42

On 16 August 2017 at 03:56, Costin Manolache <costin@gmail.com> wrote:
> IMHO out-of-band discovery may be sufficient - in webpush it is implicit or
> can be part of the
> subscribe handshake. If VAPID is used with an API the supported auth may be
> part of the API
> schema/discovery.
>
> I think in future it may be valuable to add an optional certificate - either
> as an extra header or parameter -
> to allow authentication without a database RT. In such mode a mechanism to
> discover supported
> roots may be needed - however it can also be done out-of-band.
>
> B
>
> Costin
>
>
> On Tue, Aug 15, 2017 at 10:12 AM, Alexey Melnikov <aamelnikov@fastmail.fm>
> wrote:
>>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-webpush-vapid-03: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I have cleared my DISCUSS based on changes in git.
>>
>> I am looking forward to continuing discussion about advertising support
>> for the
>> "vapid" authentication scheme in WWW-Authenticate:
>>
>> In Section 3, 3rd para:
>>
>>    This authentication scheme does not require a challenge.  Clients are
>>    able to generate the Authorization header field without any
>>    additional information from a server.  Therefore, a challenge for
>>    this authentication scheme MUST NOT be sent in a WWW-Authenticate
>>    header field.
>>
>> Does this mean that there is no way to discover whether a particular
>> server
>> supports "vapid" HTTP authentication scheme?
>>
>>
>> _______________________________________________
>> Webpush mailing list
>> Webpush@ietf.org
>> https://www.ietf.org/mailman/listinfo/webpush
>
>