Last Call Review of draft-ietf-webpush-vapid-03
review-ietf-webpush-vapid-03-opsdir-lc-winter-2017-07-03-00

Request Review of draft-ietf-webpush-vapid
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-07-03
Requested 2017-06-19
Other Reviews Genart Last Call review of -03 by Joel Halpern (diff)
Secdir Last Call review of -03 by Robert Sparks (diff)
Review State Completed
Reviewer Stefan Winter
Review review-ietf-webpush-vapid-03-opsdir-lc-winter-2017-07-03
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/6lrunrqbkf2uQWPILO-noW6z02I
Reviewed rev. 03 (document currently at 04)
Review result Has Issues
Last updated 2017-07-03

Review
review-ietf-webpush-vapid-03-opsdir-lc-winter-2017-07-03

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