Subject: Opsdir last call review of draft-ietf-webpush-vapid-03

From: Stefan Winter <[email-masked]>
Date: Mon, 03 Jul 2017 08:57:28 -0700

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 3 Jul 2017 12:31:15 -0500

> {"typ":"JWT","alg":"ES256"}base64: ungültige Eingabe

I'll let the authors respond to your other points; but, as this is 
simply a mechanical issue, I'll try to clarify the intended syntax (NOTE 
TO AUTHORS: THERE IS STILL AN ERROR THAT NEEDS FIXING).

"t" contains a JWT, which consists of three separate base64 encoded 
fields, delimited by a "." character: a header, a body, and a signature. 
The signature, naturally, does not render as something readable when 
decoded. Thus:

# echo eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9 | base64 --decode

{"typ":"JWT","alg":"ES256"}

# echo 
eyJhdWQiOiJodHRwczovL3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx0bzpwdXNoQGV4YW1wbGUuY29tIn0 
| base64 --decode

{"aud":"https://push.example.net","exp":1453523768,"sub":"mailto:[email-masked]

# echo 
i3CYb7t4xfxCDquptFOepC9GAu_HLGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA 
| base64 --decode | od -tx1

0000000    8b  70  98  6f  bb  78  c5  fc  42  0e  ab  a9  b4 53  9e  a4
0000020    2f  46  02  ef  c7  2c  69  0c  94  cb  82  19  22  b6 ae  98
0000040    94  7e  72  bd  a2  31  70  0d  76  f5  26  b1  2b  b6 6c  ac
0000060    6b  33  63  8e  f5  b6  2f  d3  a4  49  21  f3  be  80 f5
0000077

So, there is an error, inasmuch as the body is missing a closing 
quotation mark and a closing brace; but the base64 encoding is otherwise 
okay.

/a

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Jul 2017 10:14:04 +1000

> {"aud":"https://push.example.net","exp":1453523768,"sub":"mailto:[email-masked]

I get this:

$ echo eyJhdWQiOiJodHRwczovL3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx0bzpwdXNoQGV4YW1wbGUuY29tIn0
| base64 --decode
{"aud":"https://push.example.net","exp":1453523768,"sub":"mailto:[email-masked]"}base64:
invalid input

Which fills me with confidence in the base64 tool.  You'll note that
the trailing quote and curly brace are present here, but there is an
inexplicable error that adding the -i option doesn't remove.

I built this using my own implementation and verified it, but you will
see that this works too:

$ npm install base64url;node -e
'console.log(require("base64url").decode("eyJhdWQiOiJodHRwczovL3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx0bzpwdXNoQGV4YW1wbGUuY29tIn0"))'
{"aud":"https://push.example.net","exp":1453523768,"sub":"mailto:[email-masked]"}

(note that running this leaves a node_modules lying around).

https://www.base64decode.org/ also agrees.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Jul 2017 02:20:23 +0200

base64 classic seems to need padding and reacts differently on different versions when that is missing.

(I’d like to meet someone who can explain what they were thinking when they invented padding.)

Grüße, Carsten

> On Jul 4, 2017, at 02:14, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Jul 2017 10:25:01 +1000

> base64 classic seems to need padding and reacts differently on different versions when that is missing.

Ahh, another example of insufficient application of Postel's Maxim.
Adding "=" fixes this particular problem.