Subject: [Cfrg] Second RGLC on draft-irtf-cfrg-hpke

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sun, 16 Aug 2020 11:49:58 +0300

Dear CFRG participants,

This message starts a second 2-week RGLC on "Hybrid Public Key Encryption"
(draft-irtf-cfrg-hpke-05), that will end on August 31st. See
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/ for the latest
version of the draft.

We are having the second RGLC because we didn't have much feedback during
the first RGLC and because we have obtained two new Crypto Panel reviews:
https://mailarchive.ietf.org/arch/msg/crypto-panel/Ol1Mm8JUpmgapgq8ppnBQQSlEkE/
https://mailarchive.ietf.org/arch/msg/cfrg/7zhOHPFkCyZC00xLZnsEBT3o6ZU/

Please send your comments, as well as expression of support to publish as
an RFC (or possible reasons for not doing so) in reply to this message or
directly to CFRG chairs.

Regards,
Stanislav, Nick and Alexey

---

From: Watson Ladd <[email-masked]>
Date: Sat, 29 Aug 2020 16:03:16 -0400

On Sun, Aug 16, 2020 at 4:51 AM Stanislav V. Smyshlyaev
<[email-masked]> wrote:
>
> Dear CFRG participants,
>
> This message starts a second 2-week RGLC on "Hybrid Public Key Encryption" (draft-irtf-cfrg-hpke-05), that will end on August 31st. See https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/ for the latest version of the draft.
>
> We are having the second RGLC because we didn't have much feedback during the first RGLC and because we have obtained two new Crypto Panel reviews:
> Please send your comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs.

I support publication

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 31 Aug 2020 09:13:44 -0700

On Sun, Aug 16, 2020 at 1:51 AM Stanislav V. Smyshlyaev <[email-masked]>
wrote:

> Dear CFRG participants,
>
> This message starts a second 2-week RGLC on "Hybrid Public Key
> Encryption" (draft-irtf-cfrg-hpke-05), that will end on August 31st. See
[Joe] I have reviewed this draft and I believe it is ready for publication.

---

From: Christopher Patton <[email-masked]>
Date: Mon, 31 Aug 2020 10:26:11 -0700

I support publication. Below are some minor editorial things that might be
worth
addressing if there's time to do so.

Best,
Chris P.

Abstract

"for any combination of" -> "for several combinations of"

Section 4

"random(Nsk)" is used but "random()" isn't defined yet.

"not passed as parameter" -> "not passed as a parameter"

Section 5

"the holder of the private key corresponding to `pkR`" -> "the holder of
`skR`"

In various places, e.g., 'KeySchedule()' in Section 5.1, value "" is used
as the
salt for KDF extraction. I'm wondering if implementations might
misinterpret
this. I read "" as 'the empty string', but the correct interpretation might
be
'nil', i.e., 'None' in Python or 'NULL' in C. The HKDF spec defines the
salt as
follows: 'optional salt value (a non-secret random value); if not provided,
it
is set to a string of HashLen zeros.' I think the intention is to interpret
""
as 'nil', i.e., no salt, but the empty string is certainly a valid salt for
HKDF, since the extraction function is well-defined on this input. A
0-length
salt might not be safe choice in terms of security, however.

Section 5.2

I think the HPKE uses the term "nonce" incorrectly, since it's not a "Number
that's used ONCE". In fact, it's used every time the "Seal()" or "Open()"
operation is run. What's called a "nonce" here is usually called the
"initialization vector" elsewhere: in TLS 1.3 for example, the "nonce" is
the
initialization vector XORed with a sequence number.

On Mon, Aug 31, 2020 at 9:14 AM Joseph Salowey <[email-masked]> wrote:

>> We are having the second RGLC because we didn't have much feedback
>> during the first RGLC and because we have obtained two new Crypto Panel
>> reviews:
>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 31 Aug 2020 15:19:24 -0400

Hi Chris,

Couple responses inline.

On Mon, Aug 31, 2020 at 1:27 PM Christopher Patton <cpatton=
[email-masked]> wrote:

> this. I read "" as 'the empty string', but the correct interpretation
> might be
> follows: 'optional salt value (a non-secret random value); if not
> provided, it
> is set to a string of HashLen zeros.' I think the intention is to
> interpret ""

I've been writing C++ lately, so I'll contribute the following:

auto salt = std::optional<std::vector<uint8_t>>(std::nullopt); // or...
auto salt = std::vector<uint8_t>{};

If you look at the HKDF and HMAC specs, and it turns out that it doesn't
matter.  HKDF replaces a nullopt salt with exactly the same thing that HMAC
expands a zero-length key to, namely "0" * block_size (in Python
notation).  In fact, any all-zero salt of a length up to the block size
would have the same result.

I would actually prefer to keep this as "zero-length octet string" and
*not* "not provided".  In the short run, it doesn't matter, as noted
above.  In the longer run, for some hypothetical future KDF, it means that
the new KDF doesn't need to have std::optional<T> semantics, it just needs
to operate byte strings.

So I think the spec is correct as it is.  If there are places where it is
implied that a salt is not provided, we should clarify that one is, and
that it is the zero-length octet string.

> initialization vector XORed with a sequence number.

Agreed.  I assume something like "base_nonce" would work?

--Richard

>> On Sun, Aug 16, 2020 at 1:51 AM Stanislav V. Smyshlyaev <
>> [email-masked]> wrote:
>>
>>> Dear CFRG participants,
>>>
>>> Encryption" (draft-irtf-cfrg-hpke-05), that will end on August 31st.
>>> See https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/ for the
>>> latest version of the draft.
>>>
>>> Please send your comments, as well as expression of support to publish
>>> as an RFC (or possible reasons for not doing so) in reply to this message
>>> or directly to CFRG chairs.
>>>
>>>

---

From: Christopher Patton <[email-masked]>
Date: Mon, 31 Aug 2020 12:32:18 -0700

> Agreed.  I assume something like "base_nonce" would work?

"base_nonce" still sounds like it's a nonce. I would suggest something like
"iv".

Best,
Chris P.