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

JR Conlin <jconlin@mozilla.com> Wed, 19 April 2017 22:44 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 88199127337 for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 15:44:35 -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, HTML_MESSAGE=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 (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 GQAslhKO53Kn for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 15:44:33 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 37DF7129B63 for <webpush@ietf.org>; Wed, 19 Apr 2017 15:44:33 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id 75so19916866lfs.2 for <webpush@ietf.org>; Wed, 19 Apr 2017 15:44:33 -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=k/eP00OAoxDYBK7E+I5MU4QlyVjjoBstz0lxB+LIcEM=; b=Zdscgg/wqkN7R55ZXMbgJu7vbASgNaBfhq5E56Em1nN4fRBYqEfVF5E3NYopWA36uG h2a8p+ynuXGXisbM+uu/qrkveDGqK9HVTZe50ftzoxcdfNypJCx/wFPbWjgWULV0Nyoq hHsQssOV8djDpuWKIMBz29cwSoQR6MjiNUItA=
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=k/eP00OAoxDYBK7E+I5MU4QlyVjjoBstz0lxB+LIcEM=; b=X7HYHt9kpK+fsnkD1zlAkBpT9OB2g8tH4UCheCFVYyCcQuT9ZwdaM7piSiwnm8UlMz DivGicaQrxQDNs1HrPrshlLH570wkBlN2dTobqrC2ah5XsU+wfhC71D6SAIIebwOMlUQ s2nemVI+OcDnm1972Bfx2EeR6XJEkefjYoD0P7ExyZ6ybHUZGSKAN0qKUqJkKHH1QaBs xFe2KUcDhbjyTypXcFHyW4UxOOgCPP2o1GWopHcRpAxfmc8nEBh2FYVogwErCItZ+k5k ejOX82unFoAKGfJQplI/1L+4qtunG08yYDlYamVBVzKiAj/uTsnqzDXeJOq5UDe0bE2Z AH+g==
X-Gm-Message-State: AN3rC/7jdhgo2qMPPXPwTFp242pUoDmndy4LsWSi42R2OJFY2xyRVENL 4KHZDcZglQ37YBkkTkNVmghOuHlLKfocCHM=
X-Received: by 10.25.163.134 with SMTP id m128mr1800738lfe.1.1492641871333; Wed, 19 Apr 2017 15:44:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 15:44:30 -0700 (PDT)
Reply-To: jrconlin@mozilla.com
In-Reply-To: <CA+XEteNJp6WJSrS-jC2sOBcJEXOG_TVD3eY0Zxj2w7_fepbRug@mail.gmail.com>
References: <CA+XEtePZfEMv2AOCsF4O0NxTedMm3cK07UxZy2bwrEQk+ME98Q@mail.gmail.com> <CAEeQnY+8DWASaPMC=mkMv-HJ6Xbw4xUXY+=50kqijfDPg+-dpA@mail.gmail.com> <CA+XEteNjNtkj=8LYZ89mJzmXDuu2LJtV7W3M5zNgJfOM7n6v9g@mail.gmail.com> <CAEeQnY+cE-H5XOCnQL=oebF0umNQFX5OPAQ+RB-L9aoBfwdp5Q@mail.gmail.com> <CA+XEteNJp6WJSrS-jC2sOBcJEXOG_TVD3eY0Zxj2w7_fepbRug@mail.gmail.com>
From: JR Conlin <jconlin@mozilla.com>
Date: Wed, 19 Apr 2017 15:44:30 -0700
Message-ID: <CA+XEteMC1S7dzv2MryigpOU6umJKL5C=dTCiR_bJOOS6PpjqOQ@mail.gmail.com>
To: John Reid Conlin <jrconlin@mozilla.com>
Cc: Kit Cambridge <kit@mozilla.com>, "webpush@ietf.org" <webpush@ietf.org>
Content-Type: multipart/alternative; boundary=001a11410b4e84a77c054d8cc4c7
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/6Zqco4tqJuwwt2d-GAgA9KOx7a4>
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 22:44:36 -0000

And I've just realized that I have mislabled it as "contenttypes" instead
of "contentencodings".

On Wed, Apr 19, 2017 at 2:55 PM, JR Conlin <jconlin@mozilla.com> wrote:

>
> On Wed, Apr 19, 2017 at 2:41 PM, Kit Cambridge <kit@mozilla.com> wrote:
>
>> 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.
>>>
>>
>> I don't follow, apologies. For Autopush, we already keep client info in
>> the router table: its UAID, last connect time, and whether it uses Web
>> Push, Simple Push, FCM, or APNs. We need to look this up regardless of
>> whether we store or immediately deliver the message. It's not clear to me
>> why we'd need to guess, or who the third party is. I think I'm missing
>> something, though. Could you please elaborate?
>>
>
>
> ​Certainly. It's true that for our server, we do track the state of a
> previously connected UA for up to 30 days. (If a UA has not connected in 30
> days, we consider that UA to be "unavailable" and reject messages.) The
> problem is that the client would still need to inform the push server which
> content types it supported, much the same as it would need to tell the
> subscription provider. ​
>
> The crux of this is that the Push Service is the "third party". It doesn't
> care what the encryption format is, since it just passes the data on. The
> two parties of interest in this case are the User Agent (which is
> responsible for decoding the final message) and the Subscription Provider
> (which is responsible for encoding the message). The Push Service may do
> some minimal, superficial checks of the message it's carrying, in order to
> reduce the traffic costs to the UA, but it cannot do a full check since
> that would presumably require deciphering the message.
>
> That's why I feel it's best to keep the pertinent information in the
> exchange between the UA and the subscriber directly, much like how the
> public key comes from the UA and not the Push Server.
>