Re: [Webpush] User Agents should return a list of supported encryption content types

JR Conlin <jconlin@mozilla.com> Wed, 19 April 2017 21:13 UTC

Return-Path: <jconlin@mozilla.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 11A31129B15 for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 14:13:44 -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, HTML_MESSAGE=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 (1024-bit key) header.d=mozilla.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 bBSRBvxepZSh for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 14:13:42 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 B78A11293D9 for <webpush@ietf.org>; Wed, 19 Apr 2017 14:13:41 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id 88so19104857lfr.0 for <webpush@ietf.org>; Wed, 19 Apr 2017 14:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zVb8u9FB1hozNNGq1QflMvIBOpeSsDVoBxGeHg5Nyn8=; b=KjrjbOARtupbAJCyeF7ZUUBQzDcdvWGibl0w+y8hLxBm4MIjBhsjEZ/q8IhROQ1SW3 T12fGIhr1RVGOn4XdVBM5oTjws2r3cf2kinnEE0dyCftovZOaqouHAokvMzD/mFjbDHD N2kgaCC/a82XOSlw2IHMcseqx4r8R1nJ6gYYo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=zVb8u9FB1hozNNGq1QflMvIBOpeSsDVoBxGeHg5Nyn8=; b=NbO4r7CC7hHl++MZhVu6cf8pbJvUiILNtsAFjcipaW4q+IFKx8KUfwuzOKFxeBAwUE kBSpfggqvPnZ5h/myCwshRXMSN8Cvwl47/BZHNt3D9wKzv6w6aYRTqIMZzlBxD1C/vGd cHJ80h7zp06kZ+luYcMw5KwSU0G52YJ4qtjiXkP9ezG9PlS80v3ZZa/8efKiFypJYcb4 H3qED1aL6e79oxONUb3b3ye1QCVu8joc9fNqykBSMcsYuCZ2V1Q7P8EHGeNSHyVFH3hM Z+fsv33M10ClrcWKoRE4p4gxnbhxGl0ataqVbr9c6jPdheVfY9OJi/NoxXqwxRa/WQQX Zbsg==
X-Gm-Message-State: AN3rC/7d0QK2U13Xe/IJ4YvD3sRg12otWIuR+EK3Do0miM0g5w+kSEtz WHajUplUZF7bxJLtiz21WrLoNG35wWbt
X-Received: by 10.25.67.81 with SMTP id m17mr1708940lfj.33.1492636419798; Wed, 19 Apr 2017 14:13:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 14:13:39 -0700 (PDT)
Reply-To: jrconlin@mozilla.com
In-Reply-To: <CAEeQnY+8DWASaPMC=mkMv-HJ6Xbw4xUXY+=50kqijfDPg+-dpA@mail.gmail.com>
References: <CA+XEtePZfEMv2AOCsF4O0NxTedMm3cK07UxZy2bwrEQk+ME98Q@mail.gmail.com> <CAEeQnY+8DWASaPMC=mkMv-HJ6Xbw4xUXY+=50kqijfDPg+-dpA@mail.gmail.com>
From: JR Conlin <jconlin@mozilla.com>
Date: Wed, 19 Apr 2017 14:13:39 -0700
Message-ID: <CA+XEteNjNtkj=8LYZ89mJzmXDuu2LJtV7W3M5zNgJfOM7n6v9g@mail.gmail.com>
To: Kit Cambridge <kit@mozilla.com>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Content-Type: multipart/alternative; boundary=f403045e9e0e94d6ae054d8b7f26
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/mlzOiNxm38UY86m2F8JoFLGk5dk>
Subject: Re: [Webpush] User Agents should return a list of supported encryption content types
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, 19 Apr 2017 21:13:44 -0000

The problems with that approach are:

1) it's reactive. The subscription provider must repeatedly re-encode and
retry a message, potentially for each UA (which could require millions of
retransmits)

2) it's non-authoritative. The push server either is told or must guess the
state of an individual client. This means that it must track known UAs
(since a message can be stored for later retrieval by the UA). Having the
"source of truth" specify what's allowed and what's not at the time of
subscription, ensures that the most accurate data is provided.

Honestly, this is a coordination point between two parties. I'm not sure
introducing a third is a good idea.

On Wed, Apr 19, 2017 at 1:55 PM, Kit Cambridge <kit@mozilla.com> wrote:

> This could be handled transparently by the push server, too. A client
> registering with the push server would indicate which schemes it
> supports. When the app server tries to send a message, the push server
> can check if the "Content-Encoding" is supported for that client, and
> immediately reject the message with a 400 if not.
>
> WDYT?
>
> Cheers,
> - kit
>
> On Wed, Apr 19, 2017 at 1:44 PM, JR Conlin <jconlin@mozilla.com> wrote:
> > Recently, a bug filed against a webpush subscription library highlighted
> a
> > shortcoming.
> >
> > https://github.com/web-push-libs/web-push-php/issues/48#
> issuecomment-295416292
> >
> > Currently, there are two in production encryption content types, "aesgcm"
> > and "aes128gcm". The "voice of authority" about what types of accepted
> > content types is the UA. The sorts of allowed encryption is not
> communicated
> > to the subscription update provider.
> >
> > I would like to propose that the returned PublishSubscription object
> > <https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription>
> > "options" object be modified to include a "contenttypes" list of allowed
> ECE
> > content types. (e.g. ['aesgcm', 'aes128gcm']) This method would also
> allow
> > future content types to be relayed. If no "contenttypes" field is
> present,
> > then the provider must assume "aesgcm" encoding, to allow for older UAs.
> >
> > This field would also help indicate "updated" UAs which can take
> advantage
> > of the newer draft specifications.
> >
> > My apologies if this is the wrong group. WebPush and ECE span several and
> > this is a case where they overlap. I will happily repost to the
> appropriate
> > group.
> >
> > _______________________________________________
> > Webpush mailing list
> > Webpush@ietf.org
> > https://www.ietf.org/mailman/listinfo/webpush
> >
>