Last Call Review of draft-ietf-webpush-encryption-08
review-ietf-webpush-encryption-08-secdir-lc-xia-2017-07-31-00

Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

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

In general, I think it's well written and prepared for the WGLC, in addition to
some nits and little problems:

1.       The word "falsification" is used in the section 1, I am not sure if
you see any essential difference between it and the "modification". Can you
clarify it?

2.       In section 2.1, the sentence "Most applications that use push
messaging have a pre-existing relationship with an Application Server": what is
the exact meaning of "pre-existing relationship"? From the context, I assume
it's a mutual authenticated and encrypted connection between the UA and AS,
right? More texts to clarify this term seem good here;

3.       The second phase listed in section 3 ("The shared secret is then
combined with the application secret to produce the input keying material")
seems to be described in details in section 3.4, not section 3.3. Please check
it. And the term "application secret" can be changed to "authentication secret"
for accuracy;

4.       In last paragraph of section 3.1, is "An Application Server" more
appropriate?

5.       For the HKDF, should the salt be the authentication secret, or a
random (16)?

6.       For formula of IKM = HMAC-SHA-256(PRK_cek, key_info || 0x01), should
the "PRK_cek" be "PRK_key" which is calculated before from auth_secret and
ecdh_secret?

7.       In Security Considerations section, the potential threats (e.g.,
eavesdropping, tempering, etc) of unprotected HTTP header fields have been
identified, but the according protection measures are not discussed here. Would
it be better to have them?

B.R.
Frank