[Webpush] AD Evaluation: draft-ietf-webpush-encryption

Adam Roach <adam@nostrum.com> Mon, 10 July 2017 23:04 UTC

Return-Path: <adam@nostrum.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 45A3813193D; Mon, 10 Jul 2017 16:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 ctX7Q4jfC8XE; Mon, 10 Jul 2017 16:04:50 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A0624131606; Mon, 10 Jul 2017 16:04:47 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6AN4jD2015808 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Jul 2017 18:04:47 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: webpush@ietf.org, draft-ietf-webpush-encryption.all@ietf.org
From: Adam Roach <adam@nostrum.com>
Message-ID: <b459a2d7-7bd3-a53d-9cdc-8126c9cc2ef9@nostrum.com>
Date: Mon, 10 Jul 2017 18:04:40 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/P6Tc6CFuO7irEbuq7Biu4Tb4sas>
Subject: [Webpush] AD Evaluation: draft-ietf-webpush-encryption
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: Mon, 10 Jul 2017 23:04:52 -0000

Webpush Encryption author --

This is my AD review for draft-ietf-webpush-encryption-08.

This document is ready for IETF last call. I have a handful of comments, 
mostly editorial, that you should treat the same as any other last call 
comments.

The notational conventions section is cute; however, I believe that it 
would benefit from being brought in line with the more conventional 2119 
boilerplate.

The final paragraph of section 2.1 uses the word "any" in a rather 
sweeping fashion, implying that the algorithms, key sizes, and 
consequent strengths for providing authentication, integrity, and 
confidentiality are immaterial. I would suggest qualifying this more 
carefully.

The summary in section 3.4 is greatly appreciated. I'm a bit confused 
about the "salt = random(16)" as something that appears in the "for 
both" section. As written, this appears to indicate that each side 
generates their own salt as input to the PRK, which I doubt works 
(unless there's some black magic at play here that I don't understand). 
Appendix A would appear to indicate that the Application Server 
generates this value, and provides it to the "receiver" (user agent?). 
This is all made somewhat more confusing by the fact that 3.3 defines 
"salt" (which is the HKDF salt rather than the PRK generation salt) to 
be equal to the authentication secret, generated by the client. Needless 
to say, it's pretty easy to get lost in all the salting -- I would 
suggest some notational distinction between them. Also, please make it 
clear in Section 3.4 who generates the salt for the PRK.

Section 4: s/the some of the length/the sum of the length/

Section 5: "base64url" needs a definition -- I would suggest citing RFC 
4648, section 5.

The final ciphertext in the appendix appears to contain a spurious space.

Please expand the following acronyms upon first use; see 
https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

  - UA - User Agent
  - HMAC - Hashed Message Authentication Code
  - PRK - Unknown
  - CEK - content-encryption key


/a