[Webpush] Opsdir last call review of draft-ietf-webpush-vapid-03

Stefan Winter <stefan.winter@restena.lu> Mon, 03 July 2017 15:57 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: webpush@ietf.org
Delivered-To: webpush@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2D713169F; Mon, 3 Jul 2017 08:57:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Stefan Winter <stefan.winter@restena.lu>
To: ops-dir@ietf.org
Cc: webpush@ietf.org, ietf@ietf.org, draft-ietf-webpush-vapid.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149909744835.22804.5791695515985213782@ietfa.amsl.com>
Date: Mon, 03 Jul 2017 08:57:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/63czyeLOvNTUOX42eqC8nweL0KM>
Subject: [Webpush] Opsdir last call review of draft-ietf-webpush-vapid-03
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 03 Jul 2017 15:57:29 -0000

Reviewer: Stefan Winter
Review result: Has Issues

Cryptographic agility is ensured by requiring an all-new protocol in case a
different algorithm is used, or any other protocol property is changed (the
newly defined auth scheme "vapid" is hard-wired to ECDSA NIST P-256, and there
is no version field in the JWT token). Considering that the JWT header and JWK
fields describe their signing method, making it cryptographically agile,
pinning the algorithm appears to be a strange choice (see the example in 2.4).

The last paragraph of Security Considerations remains a mystery to me. What is
a "gradual migration"? With no key rollover, any change of key simply breaks
all clients with using that key. The last sentence implies that such a hard
failure is acceptable. That's a rather simplistic protocol design.

The example in 2.4 does not appear to be correct. I cannot decode "t":

> base64 --decode
eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_HLGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA
{"typ":"JWT","alg":"ES256"}base64: ungültige Eingabe