Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

Martin Thomson <martin.thomson@gmail.com> Thu, 17 August 2017 00:53 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 3C6631323C0; Wed, 16 Aug 2017 17:53:40 -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, FREEMAIL_FROM=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 (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 m263RlRnZ1by; Wed, 16 Aug 2017 17:53:38 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 D42AE1323B6; Wed, 16 Aug 2017 17:53:37 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id m88so18478940iod.2; Wed, 16 Aug 2017 17:53:37 -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=9fnjha1otMAk3MCJZYVsy4ImZ2jdBlDkz3ZZLlyogeM=; b=k8VpfzTVg9W8oEIYbOeCwcDLKqdQHAuWGkaNrTTeU+8tGk9bcndG3K+4mWQu3Iy6kZ NhJgo/QAnXXDyX74N7yCZseHsWz/R1BQ0JGy7MhvfzR3Z+jFctWezKNpBxErtWYJ1dHA Agfvpc5voHmW6xMnuKwBM4ODRhkN34pV1wawVz+HiCxY3xJSxZvIF17Jw6iUJGt/PGJA Y3A6jhBKfgT0PBPCbd32zQRCZsJrmW5+cOgffmEab+pH5btcg2k5HOTtzsGNll7Fb1AO HBk8a1cjAyJvRCpjBmYFmtz4o3L5WkPKhHJboNQOPEAK2hLgcd2qQFGP1JH36T3qJfXQ TVuA==
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=9fnjha1otMAk3MCJZYVsy4ImZ2jdBlDkz3ZZLlyogeM=; b=R0ph3kND2d/iU0/PwsJqUsNy9byMmf5v8r83LZJ1t2P/j4QAMGxnlyFL703ezt+B5E 9R7C985jQW0a28wK8akPkAgkuy4rPEN/BT3TgQSmNcJGwvkc/xSGtKKqVCV3OYQKpWxY IbRDWHHPDvWcTiacO++3u4h06ijIl1uEV0cSLryBB534ib/COKnPKcoPv4wTLHt+NhBm XfV7QOiECD/8GSAOFKXFt/bRrVBgo39R599iY+zUuq+VOjl3IJKi8DaTHkzvubHVbHt4 KAJyUO84tzW04LZdLj5vUnmD7DNh8dQwWKHVTx5UWYyr25RERz7hvIZafh1k9tR4vhPk 4UIw==
X-Gm-Message-State: AHYfb5hDjUVD7P7P7sJSewJOCeJhHmSlzb6GlKw8tAp4aozEYKBse42S QmZfq0FFnFVSoNuNIgo+U2TINkHw1w==
X-Received: by 10.107.137.30 with SMTP id l30mr3519818iod.279.1502931217228; Wed, 16 Aug 2017 17:53:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 17:53:36 -0700 (PDT)
In-Reply-To: <CABcZeBNNCeqCMA3M+dYC-r1eUpoRhXk45Bn0if-3Kb8usK-44w@mail.gmail.com>
References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <CABkgnnXwUpp4A=V6gNXoK+Q6LatCHFoB59+xVd0RxQ96Y5gfaQ@mail.gmail.com> <CABcZeBP1Ej2Dd7rPTn6Sq3uVLA1gPHBSRSQR2Fam_mxJqcQgig@mail.gmail.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> <CABkgnnWG8dDMAZe0MdAf0D7WE1jzA+yPJEAMsH9siL56cNbz1Q@mail.gmail.com> <CABcZeBNNCeqCMA3M+dYC-r1eUpoRhXk45Bn0if-3Kb8usK-44w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 17 Aug 2017 10:53:36 +1000
Message-ID: <CABkgnnVfys1ZpfG0UrwikYunxrqxTvK6shSbgM16mWbZsFe+2Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Adam Roach <adam@nostrum.com>, Ben Campbell <ben@nostrum.com>, draft-ietf-webpush-vapid <draft-ietf-webpush-vapid@ietf.org>, Phil Sorber <sorber@apache.org>, The IESG <iesg@ietf.org>, webpush-chairs@ietf.org, "webpush@ietf.org" <webpush@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/W_6DdlpW2sL4MZh1ONUNSb4vJEM>
Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and 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: Thu, 17 Aug 2017 00:53:40 -0000

On 16 August 2017 at 22:55, Eric Rescorla <ekr@rtfm.com>; wrote:
> Finally, I think this discussion has ratholed a bit on this particular
> counter-proposal. My point isn't that you should do this particular thing
> but rather that it seems like the WG decided on a bearer-token model without
> giving sufficient consideration to alternatives that have better security
> (of which this is merely one). The fact that I was able to produce two such
> alternatives in a few hours (which I'll concede are not in every way
> superior) and your response was not "yes, we considered those and here is a
> pointer to the WG archives" seems to lend that point some plausibility.

Maybe the specific suggestion was the problem.  We did discuss a
number of alternatives.  The history of this draft actually includes
those options.  Some of them did not have the unfortunate property you
don't like.  We considered client certificates, but rejected them on
operational grounds (you might think that unfortunate, because that
would be superior in many ways to all options discussed on this
thread).

Here are the options as originally presented:

https://tools.ietf.org/html/draft-thomson-webpush-vapid-00

       2.1.1.  Application Tokens  . . . . . . . . . . . . . . . . .   4
       2.1.2.  Contact Information Header Field  . . . . . . . . . .   4
       2.1.3.  Request Signing . . . . . . . . . . . . . . . . . . .   5
       2.1.4.  Token Binding . . . . . . . . . . . . . . . . . . . .   5

I apologize for my reaction.

> I think I explicitly labelled this argument as flippant, but I also don't
> think it's valueless, especially when put up against "Three large companies
> implemented and are too lazy to change".

That's a strawman.  The implementations I worry about are those in the
very many application servers.  The limited number of push service
operators have demonstrated an ability to ship changes fairly rapidly.