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

Martin Thomson <martin.thomson@gmail.com> Wed, 16 August 2017 05:09 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 E8A9A1323C8; Tue, 15 Aug 2017 22:09:46 -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, FREEMAIL_FROM=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 (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 X-qhmYpRZYK0; Tue, 15 Aug 2017 22:09:44 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 71E371321A5; Tue, 15 Aug 2017 22:09:44 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id 76so12936589ith.0; Tue, 15 Aug 2017 22:09:44 -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:content-transfer-encoding; bh=dqkq/BJ5S3M4gyVwuUp8CgWCC/dg8hkBWDCBOsIpeVY=; b=DE6dsbM/9pHEMwO5y8YQpUtFYEOwJHEuWpBy9rgNo9tR0Y/5vyCILlUme2zwWCsreL 2ItRoMhH474QKA2DBT67IO0SRFQy/nRUzW5ZSfxvwGEDervapV9AcqiG2JGlHKKXakRJ ndmTrb0ljwBMWnc9w+f7U8MOnoIbQ0/ni+SQERbwWMWO27+1YoAhFF8oa+pxDxoNprL6 eN/+PUM6o+3x2TxIDbfKt4xWSmlwHoNP2GRa4UwVnrMAi/StOQeEQJNVczjN3tQXN+Aj h5+A/Z7EkusYOlHbmOMLvUpbsme0kDfdNPkb8ESPPS71PohnacKoNSJ4rZv0xHC1zBKl D5lg==
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:content-transfer-encoding; bh=dqkq/BJ5S3M4gyVwuUp8CgWCC/dg8hkBWDCBOsIpeVY=; b=e61s25lla5pxq44KqAgkTRTIoe6jRipSD6vTinuodz3zxcw24it5mmGFhtb/l55QeW UzolCJ1CjtE4lQ1oYDXxkDLcAS16fzt9yTYFSx5gI+Syk9wz3/Oo/Bw/nhtm89mJV0q6 9mnm0/f9Sjwxg/3KAJuwZD/Kyf7gdfa2YMOzvDVuYk5CMvjFMajZj9L2Ooa9gaR34yb1 fzpPic6CrvTIxfIljZGLE0iici9hq79yuyPzGO0JnTWywW8xxsRZI8+4/8+8f0R1c4dm 0vWhrG2cgRw8rYd4Ue55yMK7fBmgv7lq7r53+VM1ZeIWP1FjlwlEjJkkEHi5qobQjXd2 XOAw==
X-Gm-Message-State: AHYfb5jefL/r4AaT39Lc1kWQlw/TrvRGm+6cPM+berYKKIafoqphrnL0 2mt1ObnnBT/To4ydBvSaKqH567BLWQ==
X-Received: by 10.36.107.68 with SMTP id v65mr962701itc.129.1502860183071; Tue, 15 Aug 2017 22:09:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 22:09:42 -0700 (PDT)
In-Reply-To: <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 16 Aug 2017 15:09:42 +1000
Message-ID: <CABkgnnWG8dDMAZe0MdAf0D7WE1jzA+yPJEAMsH9siL56cNbz1Q@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Ben Campbell <ben@nostrum.com>, Eric Rescorla <ekr@rtfm.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"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/xHQMsSLI0HXz64eievp3nrr3jXg>
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: Wed, 16 Aug 2017 05:09:47 -0000

On 16 August 2017 at 12:35, Adam Roach <adam@nostrum.com>; wrote:
> On 8/15/17 9:31 PM, Ben Campbell wrote:
>>
>> My knee jerk response is to agree with Ekr. But it’s worth discussing how
>> big of an incompatibility with existing code people are talking about. Are
>> there a lot of deployed services that support vapid? Do people think that
>> existing implementors will choose not to implement/deploy the additional
>> protection?
>
>
>
> My inclination is to ask the WG to weigh in on this issue in particular.
> I've received some pretty confident responses indicating that VAPID has no
> issues with crypto-agility. Given that such is the case, it seems like the
> question of how many deployed implementations we have is pretty irrelevant:
> if we can't change crypto schemes at scale, then we shouldn't publish this
> document anyway.

No change is free.  We'd first have to establish whether the change is
a net gain.

The presumption here seems to be that the presented design is
unconditionally superior.  That's not true.  This is a trade-off, and
- in my opinion - not one that favours any change.

For me the important point here is that the proposed change (in any
form) is of fairly marginal value.  Yes, the IETF is investing in
anti-bearer-token-theft technology, but in this case what you get is
the ability to send a message to user agent and wake it up.

You get that after stealing two pieces of information: the push
subscription URI and this token.  (That's assuming that the first was
not already sufficient, which it is in some cases.)  You can't send
arbitrary data, for that you need two more pieces of information: a
public key and authorization code, and neither of these appear on the
HTTPS connection from which the other items were stolen.

So that's benefits.  Let's talk about costs.

If we take the suggested design the biggest challenge is key
management for K_p (the key that the push service would have to
maintain).  Maintaining a set of keys across a globally-distributed
service isn't free.  Given that key compromise would undermine the
effort we'd be putting in here, you also need a strategy for updating
those keys and revocation of old or compromised keys.  For that you
want multiple keys, which means key identifiers in messages.  You also
need some way of having application servers update their view of what
keys are current, maybe using expiration times.

Technically, we also have to work out what to cover with the MAC.  My
experience with HTTP and signing suggests that this isn't as trivial
as it might seem.  I think that we could canonicalize the push
subscription URI, Content-Encoding header field and payload and be
reasonably sure that the MAC couldn't be transplanted.  Probably also
the RFC 8030 TTL, Urgency and Topic header fields, which suggests that
there needs to be a way to sign any new and relevant header fields
that might be added later.  This would need some more analysis than
I've given it here.

Then we have to decide whether this is a mandatory part of the
mechanism.  It's marginally easier if it isn't, but the arguments ekr
has presented suggest that he thinks it should be.  That makes the
deployment story harder.  For that, we really would want to exercise
the cryptographic agility Adam refers to here.  It's possible that we
don't need to worry too much about removing the old stuff on the basis
that it's all voluntary anyway, but now there are two things that need
to be implemented and supported.  What incentive have we provided to
use the new thing as opposed to the old thing?

To answer Ben's question: there are a small number of push services
(one for each browser, effectively http://caniuse.com/#feat=push-api),
but a LOT of application servers.

And to briefly address the costs of the other alternative: Doing
something like token binding has a bunch of implementation costs.  It
cross layers in ways that make it difficult to both implement and
deploy.  For instance, we couldn't deploy it without
draft-campbell-tokbind-ttrp being supported by our vendors.  This is
the same reason we considered and rejected client certificates for
this - one of the many alternatives that were considered.

p.s., It's been a while since I've been on the receiving end of the
old "your code doesn't matter, you took a risk implementing an I-D"
argument.  As an argument it kinda stinks.  I'm embarrassed to confess
that I've used it in the past, despite reminding myself not to.  I'd
be interested in learning whether the IESG has an opinion on the
subject.  A statement of policy might be valuable.