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

"Xialiang (Frank)" <frank.xialiang@huawei.com> Tue, 25 July 2017 05:47 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD2F126DC2; Mon, 24 Jul 2017 22:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] 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 6YjvtAUtQadM; Mon, 24 Jul 2017 22:47:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A00126B7E; Mon, 24 Jul 2017 22:47:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRY34306; Tue, 25 Jul 2017 05:47:38 +0000 (GMT)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Jul 2017 06:47:37 +0100
Received: from DGGEML502-MBX.china.huawei.com ([169.254.2.84]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Tue, 25 Jul 2017 13:47:33 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "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: =?utf-8?B?562U5aSNOiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtd2VicHVzaC1l?= =?utf-8?Q?ncryption-08?=
Thread-Index: AdMEaPQXX4vDafpiRhyauKY8V1g8+QAQAEwAABDzc2D//54wgP//ZMuw
Date: Tue, 25 Jul 2017 05:47:33 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12BB27953@DGGEML502-MBX.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12BB2742F@DGGEML502-MBX.china.huawei.com> <CABkgnnWzNX8mO+9q73RRySdStDmmi5ifOY55+QwkMH1e_BVRtw@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F12BB278AF@DGGEML502-MBX.china.huawei.com> <CABkgnnXbLm_93mUv64WXypEt0E+myZWaZ4XaTpQSdV15mvNtzA@mail.gmail.com>
In-Reply-To: <CABkgnnXbLm_93mUv64WXypEt0E+myZWaZ4XaTpQSdV15mvNtzA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5976DB7B.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.84, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fa1a073681d43f6078cdd65ae021b313
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/6wE0iKyBOoUHKsWILu7fdTPHsHw>
Subject: [secdir] =?utf-8?b?562U5aSNOiDnrZTlpI06IFNlY2RpciByZXZpZXcgb2Yg?= =?utf-8?q?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: Tue, 25 Jul 2017 05:47:44 -0000

I see, thanks!
No more comments...

-----邮件原件-----
发件人: Martin Thomson [mailto:martin.thomson@gmail.com] 
发送时间: 2017年7月25日 12:32
收件人: Xialiang (Frank)
抄送: iesg@ietf.org; secdir@ietf.org; draft-ietf-webpush-encryption.all@ietf.org
主题: Re: 答复: Secdir review of draft-ietf-webpush-encryption-08

No, there is only one authentication secret.  The second salt doesn't carry any significance (it just helps avoid key and IV reuse).

On 25 July 2017 at 12:28, Xialiang (Frank) <frank.xialiang@huawei.com>; wrote:
> Hi Martin,
> Thanks for your quick response and actions to my comments.
>
> I only have one question left: so you mean there are two authentication secrets generated respectively in UA and AS?
>
> B.R.
> Frank
>
> -----邮件原件-----
> 发件人: Martin Thomson [mailto:martin.thomson@gmail.com]
> 发送时间: 2017年7月25日 10:16
> 收件人: Xialiang (Frank)
> 抄送: iesg@ietf.org; secdir@ietf.org; 
> draft-ietf-webpush-encryption.all@ietf.org
> 主题: Re: Secdir review of draft-ietf-webpush-encryption-08
>
> Hi Frank,
>
> Thanks for the review. I've put changes on github here:
> https://github.com/webpush-wg/webpush-encryption/pull/16
>
> On 24 July 2017 at 20:38, Xialiang (Frank) <frank.xialiang@huawei.com>; wrote:
>> 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?
>
> The word was used intentionally to include protection against the ability to generate an inauthentic message.
>
>> 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;
>
> I've expanded this a little.
>
>> 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;
>
> Section 3.3 is correct.  Section 3.4 is an overview of the entire process.
>
> "authentication secret" is a good catch there.
>
>> 4.       In last paragraph of section 3.1, is “An Application Server” more
>> appropriate?
>
> Yes, thanks.
>
>> 5.       For the HKDF, should the salt be the authentication secret, or a
>> random (16)?
>
> In the case that you refer to, the authentication secret is correct.
> There are two randomized inputs in the entire process: the authentication secret is generated by the User Agent, and the salt is generated by the Application Server.  Both are random(16) when generated, but then they are distributed to the other side.
>
>> 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?
>
> Obviously PRK_cek isn't generated until after this point, so you are 
> right.  (That's an editing error on my part.)
>
>> 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?
>
> This is implied, but the mitigation is to discard them.  I've made this clearer.