Message Encryption for Web Push
draft-ietf-webpush-encryption-09

[Ballot comment]
Just a few minor and editorial comments:

Substantive:

- 1: "For efficiency reasons, multiple users of Web Push often share a
  central agent that aggregates push functionality."

Is the "central agent" a push server, application server, or something else?

Editorial:

-1: "Web Push messages are the payload of an HTTP message " - Plural disagreement.

-1.1: Please consider using the boilerplate from RFC 8174.

-4, first paragraph: s/ "... some of the length..." / "... sum of the length ..."

[Ballot comment]
Moving to No Objection because my DISCUSS is fixed in:
https://github.com/webpush-wg/webpush-encryption/commit/645a04b3b86ffe10322134e27a3d3c5eb5a8b06b

Note, I think technically only the UA needs to do point verification if the app generates a fresh key as
implied by S 2. It would also be nice to have a cite to how to do the point verification. This text can be
stolen from TLS 1.3.


S 1.
  This document describes how messages sent using this protocol can be
  secured against inspection, modification and falsification by a Push
  Service.

"forgery" is more customary than falsification.


S 3.3.

  key_info = "WebPush: info" || 0x00 || ua_public || as_public

You should make clear that the string is not null-terminated. Ugh, I know.


S 3.4.
You should clearly separate which pieces are defined in this document
and which are defined in the HTTP encryption document.

[Ballot comment]
S 1.
  This document describes how messages sent using this protocol can be
  secured against inspection, modification and falsification by a Push
  Service.

"forgery" is more customary than falsification.


S 3.3.

  key_info = "WebPush: info" || 0x00 || ua_public || as_public

You should make clear that the string is not null-terminated. Ugh, I know.


S 3.4.
You should clearly separate which pieces are defined in this document
and which are defined in the HTTP encryption document.

[Ballot comment]
Firstly, thanks to Tim Chown for his helpful OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-webpush-encryption-08-opsdir-lc-chown-2017-08-01/ ) and for your response.

I only have nits on this document:
1:  I reviewed this and draft-ietf-webpush-vapid together. This document uses title case for "User Agent" (and many other terms), while draft-ietf-webpush-vapid and RFC8030 uses lower-case. Consistency would be nice here.

2: Section 2:
"In addition to the reasons described in [I-D.ietf-webpush-protocol], this ensures that the authentication secret is not revealed to unauthorized entities, which can be used to generate push messages that will be accepted by the User Agent." -- this is ambiguous / confusing. It is unclear which which is which. I'd suggest rewording to something like "... to unauthorized entities, which would allow that entities to generate push messages that would be accepted by the User Agent as valid" (or similar)

3: Section 7.  Security Considerations
"In particular, any HTTP header fields are not protected by the content encoding scheme." -- I think you may mean "In particular, no HTTP header fields are protected ..." (or similar)

[Ballot comment]
This is really well written and clear. Thank you for that.

I found “for efficiency reasons” in this text

  For efficiency reasons, multiple users of Web Push often share a
  central agent that aggregates push functionality.

To be so broad that I wasn’t sure what you were telling the reader. Are there any specific efficiencies that you could call out, so that we’d better understand why central agents are used? And if that’s already written down someplace, adding a pointer would be even better.

I’m curious about algorithm agility, but I’m not the person to ask that question ...

[Ballot comment]
This is a fine document. One nit:

4.  Restrictions on Use of "aes128gcm" Content Coding

  An Application Server MUST encrypt a push message with a single
  record.  This allows for a minimal receiver implementation that
  handles a single record.  An application server MUST set the "rs"
  parameter in the "aes128gcm" content coding header to a size that is
  greater than the some of the length of the plaintext, the padding

s/some/sum ?

  delimiter (1 octet), any padding, and the authentication tag (16
  octets).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-webpush-encryption-08.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, Phil Sorber , sorber@apache.org, draft-ietf-webpush-encryption@ietf.org, webpush-chairs@ietf.org, webpush@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Message Encryption for Web Push) to Proposed Standard


The IESG has received a request from the Web-Based Push Notifications WG
(webpush) to consider the following document: - 'Message Encryption for Web
Push'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  A message encryption scheme is described for the Web Push protocol.
  This scheme provides confidentiality and integrity for messages sent
  from an Application Server to a User Agent.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Phil Sorber. The responsible Area Director is Adam Roach.

In this document a message encryption scheme is described for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an Application Server to a User Agent.

2. Review and Consensus

The document had consensus in the working group, but there was not a lot of activity. I became chair of the working group after most discussion had concluded, but reading back through the mailing list there did appear to be thoughtful discussion on it. There is an implementation in the works for at least one browser. I reviewed it and only had minor edits. I asked Matt Miller to also do an in-depth review with regard to the cryptographic content of the draft, and he only had editorial comments. I do believe this document is ready for publication.

3. Intellectual Property

The author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

There are four normative downrefs. Three are to non-RFC references and one to RFC 5869 which is on the DOWNREF registry. All are cryptography related.

    Non-RFC normative reference: ref. 'ECDH'
    Non-RFC normative reference: ref. 'FIPS180-4'
    Non-RFC normative reference: ref. 'FIPS186'
    Normative reference to an Informational RFC: RFC 5869

There are no IANA considerations and the author has left a note to the RFC editor to remove that section for publication.