[secdir] Secdir review of draft-ietf-webpush-encryption-08

["Xialiang (Frank)" <[e-mail]>]

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