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

JR Conlin <jconlin@mozilla.com> Wed, 19 April 2017 21:55 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 0128712785F for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 14:55:27 -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 oBRaqGWZ7cmj for <webpush@ietfa.amsl.com>; Wed, 19 Apr 2017 14:55:25 -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 ADB011243FE for <webpush@ietf.org>; Wed, 19 Apr 2017 14:55:24 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id t144so19531826lff.1 for <webpush@ietf.org>; Wed, 19 Apr 2017 14:55:24 -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=6+B7PjxtRBRTK1vqvj+NsgK5D6c+8V8qw3gFONGbsMU=; b=QKaL0diCOaHwAK3QLly2Ir9pnEB5iyq92AVpYcuNoOFZjD3oseyD8Ral/Q/awi3ILJ VJDmTJFcvpm7t0lVxbustZE5zQiu17ZED3OThlFCNPiBumbyJOC4HS6lab1/tBt8TmJm BUxVMqLF2LZJZSgcydsl6fwn2F5KJ+KIrlwfM=
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=6+B7PjxtRBRTK1vqvj+NsgK5D6c+8V8qw3gFONGbsMU=; b=U97RhSG7+OlFjKC3D2PA02TB8I7aR6eD6c34lI2rmQBb+rJKmzgPFuyLRMLFQyFRc9 wXsmdKVIX9nWHK8VxkyYt/z4YDLIHrOQi3XQDwglb7jpxqStqOZNt6DZ6ScrKLWC95Rl ItQGL93lXbmmsCxzyzxfkz4hV0TS1snzt3uepHydMllTUJiCBDVCKSOy837lvgYmBlTL LdY5keCU3BLpKZxRi2NvAvV714pLh2MyaNOxmbiFomDXf+jQeucYr+EJmEGfSPzWsGAs +O7+Cwldx2DoOLd1bCiZglRmN934WHoTBtoBigV/U09/gGGziMVuGtHaC/igYr7iIh2e 4+aQ==
X-Gm-Message-State: AN3rC/5AHFc2qH3IMzSP3hKM2hHq2NFnD6wc4qrwb9awCTYzmUI9ZuYx GLVcZ0rZzIARgrL1PeG5AsMW4NBprAhG
X-Received: by 10.25.67.81 with SMTP id m17mr1748113lfj.33.1492638922730; Wed, 19 Apr 2017 14:55:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 14:55:22 -0700 (PDT)
Reply-To: jrconlin@mozilla.com
In-Reply-To: <CAEeQnY+cE-H5XOCnQL=oebF0umNQFX5OPAQ+RB-L9aoBfwdp5Q@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>
From: JR Conlin <jconlin@mozilla.com>
Date: Wed, 19 Apr 2017 14:55:22 -0700
Message-ID: <CA+XEteNJp6WJSrS-jC2sOBcJEXOG_TVD3eY0Zxj2w7_fepbRug@mail.gmail.com>
To: Kit Cambridge <kit@mozilla.com>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Content-Type: multipart/alternative; boundary=f403045e9e0ec4bf9d054d8c149d
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/q_aszcufqbY9Xk0KmUP0h3um1eI>
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:55:27 -0000

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.