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

"Xialiang (Frank)" <frank.xialiang@huawei.com> Mon, 24 July 2017 10:38 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D8C3F131C51; Mon, 24 Jul 2017 03:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CyxRhA8iDb-u; Mon, 24 Jul 2017 03:38:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C41512EC4B; Mon, 24 Jul 2017 03:38:23 -0700 (PDT)
Received: from (EHLO LHREML712-CAH.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLE66192; Mon, 24 Jul 2017 10:38:20 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com ( by LHREML712-CAH.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 24 Jul 2017 11:38:19 +0100
Received: from DGGEML502-MBX.china.huawei.com ([]) by dggeml405-hub.china.huawei.com ([]) with mapi id 14.03.0301.000; Mon, 24 Jul 2017 18:38:15 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-webpush-encryption.all@ietf.org" <draft-ietf-webpush-encryption.all@ietf.org>
Thread-Topic: Secdir review of draft-ietf-webpush-encryption-08
Thread-Index: AdMEaPQXX4vDafpiRhyauKY8V1g8+Q==
Date: Mon, 24 Jul 2017 10:38:15 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12BB2742F@DGGEML502-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BB2742FDGGEML502MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5975CE1D.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1619ae10b4d5fc43ff93fe00200cb012
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Vr8afndIZYKNc4Sl-Z_FyDeBj-0>
Subject: [secdir] Secdir review of draft-ietf-webpush-encryption-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2017 10:38:26 -0000


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?