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

Martin Thomson <> Tue, 25 July 2017 02:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7530B129468; Mon, 24 Jul 2017 19:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FqdTqtpoyNym; Mon, 24 Jul 2017 19:16:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B76A91201F8; Mon, 24 Jul 2017 19:16:25 -0700 (PDT)
Received: by with SMTP id h199so43756077ith.0; Mon, 24 Jul 2017 19:16:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Vv2I+KZrRbvyFgbXvswmrf6R/DFzAxwGYloBQ7LxW80=; b=ogkThKknEH2V7cAFGWLrC3Om8E+mpXNDzAklGybE+80wwLvhnzwKDO2yPsepqNZ8AG fdO2hQ5rxCXgzXdlA+odvjwIUVi/Tj3AK99gdOcTxli0McKytVf0nOIYrser1uAHsi8O XnzIfKqXE8BSuOaUjtVqOO8R74/6BR0+eDnw6Ttph2uwQ8ngV41DFmKVi4iUGcosOTnA 8j8JoNs1+HCNu1Q5CE/Du6XShdykfBTSguJuVU7ikRbP/nnjYkOMOmV5f9gpOMldEHVC frTWQzTJ5ITnd8rsXwUlJ+Y99k6Qa+XFfhvEhbIKw27C4tgVB6SydCY5EP/XHw7vV/e3 V4Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Vv2I+KZrRbvyFgbXvswmrf6R/DFzAxwGYloBQ7LxW80=; b=HNCYgAUlpP7wfzKmBABgfzes6kAjUn1EPYl3vn5nFRL1UZxbg2DqoSI6g5Wsnzatf5 WxquXsFslfAMHILKM6OcJhO8i4I1/AbGUKfNstmKLeegUPaT7wVVQAzc203tmDf9o87m facd3/CXRBhQiW+hjwM+/tw4TENYwDyPPdfT2S3xRRap5nwdFT7wq8R7/TjdK2f11F1L dFhZ3siU9xwp8fckWHeycB514MAIqNn2nC88xI+psJBGeG5a1Il0hLrb4c8sdZuuFOnq JR/Z/ZgNtNV2W23ZQEAmphviSHEgTboA6Wbttb7uEs7Jz1jI4Z+lo/TKJSOxlNX24TPT Ajsw==
X-Gm-Message-State: AIVw1103qBV50RJaWNMeB2Ey/IwTiLJjofQ7//L4P3hHc3HiNK9RyrjA mPzcliAXMRbS64jC7louTbeOqPcHVNag/Jc=
X-Received: by with SMTP id k67mr9461944ita.79.1500948984951; Mon, 24 Jul 2017 19:16:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 24 Jul 2017 19:16:24 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Tue, 25 Jul 2017 12:16:24 +1000
Message-ID: <>
To: "Xialiang (Frank)" <>
Cc: "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-webpush-encryption-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jul 2017 02:16:27 -0000

Hi Frank,

Thanks for the review. I've put changes on github here:

On 24 July 2017 at 20:38, Xialiang (Frank) <> 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.