Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02

Richard Barnes <rlb@ipv.sx> Wed, 27 November 2019 19:47 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346231209F4 for <cfrg@ietfa.amsl.com>; Wed, 27 Nov 2019 11:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 nfgx8BAmz0Qs for <cfrg@ietfa.amsl.com>; Wed, 27 Nov 2019 11:47:13 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6B01209D1 for <cfrg@irtf.org>; Wed, 27 Nov 2019 11:47:12 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id 23so18422049otf.2 for <cfrg@irtf.org>; Wed, 27 Nov 2019 11:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vl8EyM0v02Vt16vvFNXru0qNxZqmPuRdZ7XIE7PR/g4=; b=wQzN7kT+IX65GD6pFa4chIzUuixopNS09qp20DB/cdYq8r8sWCNStMTDN8kmrA1bD6 H7iy1LYfh2wIQPkYQegl3u62juKh9itfaPn56wNzQYoH5f36olxUv4E2hNZwlkSCPJ88 h96cJ4umYyWwhZPhvrzx6PQYBAOGN7FU67nRHZ8c8wH9MjyPXWmzgt+eFghHc0vX+s/j 9ukxUOqwuA7u4fbAKISvI//voFJulnCJzdQPPfV7tEo2yigF++hWwxNQIUJxNMJDQ1HG MbMNm9PiET+NzwU093cMStFlJzqAOTV6BT0AW2gXchO1CeU9LwI6VepfoNZU2lY0JaP/ 6l/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vl8EyM0v02Vt16vvFNXru0qNxZqmPuRdZ7XIE7PR/g4=; b=G/Gc9RNHHWfnEzp9bi3Cqp8nbTIAjjAX03YblCHLBJYd/ymPHzNlmUBB3yUpoy6NeF THMEXb3Gn7G1rbl5qxxRqdmOMzyFuQHLRFJVFP0VpXy+yard2D8VdntdYqQolEalmdtt y7wqj52xwZqqB5+m8CGMYj2fY/XOTyDQykxfyd4jBV3ATieN3khJiqU74M5NN5YZ13ad lqL8X4YzLqv+jQgf1XqalX/Lv8Q0yGqzU9IqtEHbOc9EXiwjgXh7rdMOVzQXLsFcTAdl pnhyOAb+00js1p4CK81IIug+qer7eTYPDhnj5jyKhAdk33xE2gjy7P/CV+6llg7Ech08 PY5Q==
X-Gm-Message-State: APjAAAVycUKYenmUkF1cYseMDxAeU0oUsTy17i88BZY1XMsN9uLT/zhH YnrFuqdnfZVJN/xApiNHMpgtyVIg1/+z6FF41zRrmDGMLiPjTw==
X-Google-Smtp-Source: APXvYqyrIIBuCJoNqWvek+BnLqqekGhXvg5Ys5JZ4voIbojoTmfGjgXSE8tJEGcuExfEplrkzGfUVzM+ShV/sOJWf0o=
X-Received: by 2002:a9d:798c:: with SMTP id h12mr4887696otm.93.1574884031795; Wed, 27 Nov 2019 11:47:11 -0800 (PST)
MIME-Version: 1.0
References: <F881AD3B-6D69-46F7-BB96-0AADD3E10CA6@ericsson.com>
In-Reply-To: <F881AD3B-6D69-46F7-BB96-0AADD3E10CA6@ericsson.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 27 Nov 2019 14:46:54 -0500
Message-ID: <CAL02cgRyibL=G-b2caRfBhazRrYfbVcbCwbi=-Y8q4WDbdMkGQ@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000047275e05985943c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/oGM87Lqans7TOoNw4L6n_16NLSs>
Subject: Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2019 19:47:15 -0000

Hi John,

Thanks for the comments.  I've reflected them in this PR:

https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/23

Couple of responses inline.

On Sat, Nov 23, 2019 at 3:22 AM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> This is a well-written and useful draft.
>
> - ”This scheme provides authenticated public key encryption”
>
>    Should mention the unauthenticated mode as well.
>

The challenge here is that we have two meanings of "authenticated".  Every
mode is "authenticated" in the sense of "authenticated encryption".  Some
modes also authenticate some information about the sender.  I'm inclined to
leave this as-is, since I don't see an easy way to reword more clearly.



> - I think it might be useful to add a sentence on ECIES and PSEC in the
> introduction to help so people searching for “ECIES” will find the draft.
>
> - “Encrypted messages convey a single ciphertext and authentication tag
> alongside a short public key”
>
>    This made me think the tag was sent a separate field. I suggest
> changing it to a sentence saying that the ciphertext includes an
> authentication tag (but some AEAD would not even have a clearly defined tag
> such as wide PRP ones like XCB.)
>
>    Also, the sentence does not seem to cover the mode that encrypts
> several plaintexts with the same ephemeral key. I assume the initiator can
> send several ciphertect with the encapsulation ot ciphertexts without the
> encapsulation like in the following sequence:
>
>    -> enc, ct1, ct2
>    -> ct3
>

Reworded this whole paragraph to be clearer.


>
> - “mode_auth”, “mode_psk”, “mode_psk_auth”
>
>    The term “auth” is not optimal as psk also provides authentication.
> Maybe it could it be changes to something related to asymmetric,
> public-key, or KEM.
>

I agree it's suboptimal, but given that this change would touch a lot of
stuff, I'm inclined to leave it unless there's a


> - I am missing a Security considerations. I think there are several things
> that could be mentioned:
>
>   -- How does an application supporting several algorithms protect against
> downgrade?
>
>   -- Should the receiver do replay protection?
>
>   -- Shortly mention that the construction in the draft protects against
> attack on earlier ECIES standards such as the Benign malleability and the
> XOR malleability.
>

Sorry, I'm not familiar with these notions.  Maybe you could propose some
text?


>   -- Stating that the protocol does not provide PFS and give some
> consideration on when that would be ok instead of setting up a TLS
> connection.
>
>   -- privacy considerations
>

We discuss some privacy considerations in the "Metadata Protection"
section. Did you have others in mind?



> - “For the NIST curves P-256 and P-521, the Marshal function of the DH
>    scheme produces the normal (non-compressed) representation of the
>    public key, according to [SECG].”
>
>    Why suddenly referring to SECG?
>

I understood that was the normal reference for point formats.  Do you have
another preference?



> - Single-Shot APIs
>
>    Should mention that this is stateless.
>
> - The document has very detailed descriptions of the parts KEM, KDF, AEAD,
> but I miss a short overview section describing which fields the initiator
> is supposed to send to the receiver and what the initiator and receiver
> need to agree on out of band. Are any information like pskID and sequence
> number supposed to be sent on the wire?
>
> - I would like to see P-384 and SHA-384. The US CNSA suite, TLS, and 3GPP
> are all using these together with AES-256. I would also like to see KMAC.
>

I added P-384 and HKDF-SHA-384.  It's not immediately clear how KMAC maps
in here, given the shape the document assumes for KDFs.  It would be
trivial to do HKDF-SHA3, but my guess is that you want something
different.



>
> Cheers,
> John
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>