[secdir] Secdir review of draft-ietf-webpush-protocol

Magnus Nyström <magnusn@gmail.com> Fri, 14 October 2016 05:06 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E81129687; Thu, 13 Oct 2016 22:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LhjjG7l9grl4; Thu, 13 Oct 2016 22:06:07 -0700 (PDT)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 430D5129674; Thu, 13 Oct 2016 22:06:07 -0700 (PDT)
Received: by mail-yb0-x236.google.com with SMTP id o189so13519929yba.1; Thu, 13 Oct 2016 22:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=VklkxCV1TbUuJx5r3SAxUFlWImUDwXWBOLcwV++tYiI=; b=l81N7SuO1dy4hHZMnkfamA48cpZGvY14jJ3TkhcWUoBrtZWd2aIZMyFXgRSOm7Nuvp ixfSp7EPan2H4vKgWo6byYudfoOiy20p7pp3uJpTzzeWcf/xR128ulJ4Bn+qxbtVZD+O ETLZIbsxEWI7ncbmnx8Jd2VfQFKhBgaR7qG1jllZGT652njK/fWfELi3yr5ozT1OnZyU EbgBLTKpQKgkvJld6H3yLT+909Bot1ALdVQWt+WWsUZ9UR9BLrzogVaW1U2VbIWjkPIV qmLRX3Q+2uy1bVGtKMwUWS2akAzbb37euX8wLT/pAVjIYEaE/fGN6bqKU9pgSADyZhE4 rUyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VklkxCV1TbUuJx5r3SAxUFlWImUDwXWBOLcwV++tYiI=; b=g7S0Fpy4ZS+xxe6jQE8/OvrFksUG5W5gDTMLtSt5P3fozMGywO5f8eGIuphJgtw0hR hh392ipZ9SVEBBrfATjLeIihjQFOJkIlbN0zPEEjp0uDrUtb+nF2YmMiks334oqN/pGr J109/KX9Q81arX39wjpZyRQNMyn9L7Mz6ejAVujzllN0vqT4uSgrKisUtwynDe7MsO9D /D3IB8bmIEtfLC9sJmzrYQ3yO1FB+9g6oLAvdwA94mDAAzjgOleCdIzYD5dpM96fAPG2 pJHm7hNudwohlvjfcg46/zk1ZfalvLLvr1I53Q7uozWDB9RA0FyVpsXkKN2MY9rxJG7m sO/w==
X-Gm-Message-State: AA6/9Rnxj2TozLtwkQM6+1KqyHgLA9Ng+RZg7Muo5EiP3W0INQ0vFdB0XnTDCcAl40/K5jD47/v132M0K+w4aw==
X-Received: by 10.37.86.87 with SMTP id k84mr9154426ybb.37.1476421566438; Thu, 13 Oct 2016 22:06:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.228.196 with HTTP; Thu, 13 Oct 2016 22:06:06 -0700 (PDT)
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Thu, 13 Oct 2016 22:06:06 -0700
Message-ID: <CADajj4Y0Yg=qFY0=YGYNRDJ2PYiNv_-zRyjC5mQ0-+qMURpVfQ@mail.gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-webpush-protocol@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0BZE0_tjOrnF-XlgpcJeN-kZ1t0>
Subject: [secdir] Secdir review of draft-ietf-webpush-protocol
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 05:06:08 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes how a user agent can establish a relationship
with a push service (a subscription) and then share that distribution
node information with various applications.

As such, the document is well written and has a comprehensive security
considerations section. The only slight concern I have is related to
the authorization of receiving push messages. The technique used is
essentially bearer tokens (knowledge of a URL). It therefore seems as
if unintended sharing of such a capability URL could cause other user
agents to get access to push notifications. I wonder if the work
around token binding in TLS (holder-of-key tokens) could be applicable
here, at least in the future.

-- Magnus