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

Kit Cambridge <> Wed, 19 April 2017 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6586712948E for <>; Wed, 19 Apr 2017 14:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dqbZ286Zk1yj for <>; Wed, 19 Apr 2017 14:42:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EA82120046 for <>; Wed, 19 Apr 2017 14:42:18 -0700 (PDT)
Received: by with SMTP id c45so31164711qtb.1 for <>; Wed, 19 Apr 2017 14:42:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T6e3Y/Je3B2KIiH8x4eRONSg5/LqSZ9sFL7b6FoD6Y0=; b=Z6hKRMlpF6y1vxeW9H1tm9f5YIZ76+7wM2I2ZGiTLesrG90d1+ZrrqPB5E+RXjVTwV eKXf5H3h8kb43DIRM6ExrmOlS+64R7HaGYwVOD8tG8tj7z7VZy2z5dEzeTYIBBv+U76u 0x4qgHpeBOcD7BYSPe2eSkSrZWj7+1NriBk4E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T6e3Y/Je3B2KIiH8x4eRONSg5/LqSZ9sFL7b6FoD6Y0=; b=uYqVvxnVolbe7BMdDSjowDqyYoScOLl3nKYAfH6BjeLAs0sSBBF9Fub2xhKCGj2vUG OIVxYANP8meLn85xTXKhAB1AnsD7i0eIThZDXFk8r0bAmUGuru8Kbh1w47INaRquv65L KbPEdugFwvpsLGK5qCKUnfu75Ao2KmpdY7xl0YVXW5Qej6ondEd66v5lwbW+2p8HpZ+b MvX8yjWLXM/dLhPaYVh/onzmeC1f6moPZzBaZvhcy6jBHbtnQ4SK7ljnct6/XbJ7gtGu kkvXORpfVKCAIRTH1SCZnKdnLTgffb+a/I9DSLE0TYfz9bfpXX+iAFoU2HPbHAy+7VuK 5pHw==
X-Gm-Message-State: AN3rC/6ZjeJbTFxJMfr+P89nZJbWwFi36QLr7O5+QTK9xigWxKo7QC8A ryc9B3MEnFMLfTxzM/dzlPHm94ifPZxA
X-Received: by with SMTP id i60mr4571461qtd.262.1492638137696; Wed, 19 Apr 2017 14:42:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Apr 2017 14:41:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Kit Cambridge <>
Date: Wed, 19 Apr 2017 14:41:37 -0700
Message-ID: <>
To: "Conlin, JR" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary=94eb2c125854f9ddc2054d8be584
Archived-At: <>
Subject: Re: [Webpush] User Agents should return a list of supported encryption content types
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Apr 2017 21:42:20 -0000

On Wed, Apr 19, 2017 at 2:13 PM, JR Conlin <> wrote:

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

That's a good point, and we've already seen that many app servers will keep
trying to deliver to expired subscriptions. Based on that, I suspect the
more likely outcome is those messages will get dropped on the floor instead
of resent. Realistically, app servers will need to keep using "aesgcm",
until "aes128gcm" is supported in all browsers and encryption libraries.
Once "aesgcm" usage is low enough, we can remove it entirely.

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

- kit